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The  U.S.  Army’s  ground  combat  vehicle  forces  are  entering  an  era 
that  will  be  marked  by  the  need  for  substantial  change  m  vehicle 
electronics,  as  new  tactics  and  an  increasingly  sophisticated 
threat  are  translated  into  specific  vehicle  design  requirements. 

Significant  design  impacts  will  occur  in  fielded  vehicles  as  a 
result  of  three  basic  effects: 

1.  New  functions  are  being  required  of  the  vehicles  and 
their  crews,  and  these  must  be  accomplished  more 
efficiently; 

2.  nore  combat  performance  is  being  required  of  and 
designed  into  key  subsystems  (e.g.,  enhanced  armament 
and  lethality); 

3.  Changes  in  these  subsystems  will  require  modification 
to  others  in  order  to  maintain  acceptable  performance 
(e.g.,  stabilization  of  enhanced  armament  and  higher 
protection  level  turrets) . 

Many  of  the  changes  that  will  occur  during  the  next  several  years 
will  be  focused  on  increasing  the  efficiency  and  speed  with  which 
a  battle  can  be  conducted.  They  will  be  accomplished,  in  large 
part,  by  automating  many  of  individual  vehicle  communications  and 
fire  control  functions  that  are  currently  accomplished  manually. 

The  brute  force  computational  power  needed  to  achieve  the  desired 
levels  of  automation  on  individual  vehicles  will  be  available  m 
the  form  of  ULSI  and  UHSIC  circuit  technologies,  which  can 
provide  compact  high-throughput  electronics  packages.  However, 
the  cost  of  this  technology,  the  accompanying  large  increase  m 
vehicle-based  data  flow,  and  very  limited  availability  of 
additional  space  inside  vehicles,  will  combine  to  create  poten¬ 
tially  significant  problems  with  the  practical  implementation  of 
these  objectives. 

The  fire  control  system  CFCS)  on  modern  combat  vehicles  has  been 
the  primary  driver  of  weapon  station  architectures,  with  the  key 
requirements  being  stabilization  and  control  of  electro-optical 
sensors  and  weapons,  sensing  of  significant  environmental 
parameters,  and  the  computation  of  weapon  pointing  commands.  It 
will  continue  to  dominate  as  automated  target  sensing  and 
classification,  and  modern  control  techniques  are  applied. 

In  March  190H,  General  F.  J.  Brown  (ref.  2)  described  a  user's 
perspective  on  battlefield  management,  defining  a  critical  need 
to  integrate  combat  systems  and  information  gathering  sources 
into  a  Data-Lmked  Maneuver  Force.  This  concept  stressed  the 
primary  importance  and  the  functionality  of  the  individual 
combat  vehicle,  with  the  tank  commander,  who  is  currently  over- 
stressed  in  intense  combat  conditions,  being  the  critical 
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General  Braun’s  recommendation  mat  to  aubatituta  technology  for  a 
wide  variety  of  repetitive,  time  consuming  and  manual  functions. 
This  must  be  accomplished  uhile  minimizing  stress  on  individual 
unit  commanders  and  not  overburdening  them  uith  additional 
duties.  A  Battlefield  Management/ Integrated  Command  and  Control 
System  (BMS/ICCS)  uill  create  a  "Force  Multiplier”  effect,  by 
providing  the  small  unit  commander  uith  the  capability  to  process 
tactical  information  in  real  time  using  vehicle-based  information 
management  systems . 

It  is  clear  that  the  individual  combat  vehicle  is  a  key  element 
in  this  concept  of  a  Data-Linked  Manuever  Force.  Current  combat 
vehicle  data  handling  and  processing  is  either  manual,  or 
integral  to  the  Fire  Control  processing  function.  Grouth  capa¬ 
bility  is  essential  and  is  recognized  as  a  major  factor  for  BMS 
and  advanced  Fire  control.  Additionally,  the  vehicle-based  BMS 
node  must  be  cepable  of  communication  uith  higher  level  systems 
Ci.e.  CCCI,  MCS),  both  uithin  the  army  and  across  other  service 
branches . 

Many  of  the  detailed  operationel  characteristics  of  a  BMS  have 
not  been  defined,  and  it  is  not  the  intent  of  this  study  to 
attempt  further  definition  of  thaee.  Our  purpose  is  to  examine 
the  probable  directions  that  uill  be  taken  and  to  evaluate  the 
resulting  impsct  on  the  architecture  of  the  combat  vehicle.  Our 
objective  is  to  lay  the  grounduork  for  a  systematic  approach  to 
grouth  that  takes  into  account  all  of  the  probable  areas  of  major 
changes  and  their  lnterrelationehipo , 

If  the  design  and  integration  of  individual,  time-phased  grouth 
objectives  in  FCS  and  BMS  are  not  coordinated  and  approached  m 
an  integrated  manner,  there  could  be  a  proliferation  of  elec- 
tronica  boxes,  softuars  modules,  and  interconnects  that  uould 
jj  quickly  become  unmanageable  and  prohibitively  costly  to  acquire 

|  and  maintain.  The  level  of  sophistication  in  neu  and  product- 

improved  ueapon  stations  requires  that  the  system  architecture  be 
carefully  planned  and  deeigned  to  accomodate  the  growth  that  will 
mast  certainly  occur  over  the  next  decade. 

This  study  examines  the  near  term  requirements  for  FCS  and  Bns  on 
the  MlAl  tank  system,  their  probable  areas  of  growth,  and  the 
hardware/software  implications  of  those  requirements.  The 
applicability  and  development  atatua  of  key  component  and  inter¬ 
connect  technologiea  are  examined,  and  a  specific  approach  is 
y  *  recommended  for  the  development  of  BMS  and  advanced  FCS  capabil- 

|  lties  on  the  MlAl  tank. 

.  The  key  information  in  this  report  will  be  found  in  sections  3, 

f  5,  and  6.  Section  3  of  the  report  discusses  the  current  and 

projected  relationships  between  the  firs  control  and  battlefield 
management  systems,  and  forms  the  foundation  for  the  approaches 
discussed  later.  Section  H  addresses  component  technologies  that 
are  significant  to  the  FCS/BMS  requirement.  while  it  supports 
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the  direction  taken  for  system  architectures,  reading  this 
section  is  not  required  for  an  understanding  of  the  systems 
issues  discussed  later. 

Section  S  summarizes  key  architectural  considerations  and 
describes  the  Ml  fire  control  system,  which  is  the  baseline  for 
the  BhS  and  advanced  FCS  architectures  described  in  section  6. 


2.  SUMMARY  AND  CONCLUSIONS 


A  nasd  has  been  identified  to  provide  an  automated  data  and 
communications  management  capability  for  future  land  combat 
forces.  The  exact  nature  of  the  communications  networks  and 
interfaces  that  will  comprise  future  Battlefield  Management 
Systems  have  not  all  been  defined.  However,  it  is  clear  that  a 
primary  element  of  that  structure  will  be  a  communications  and 
data  processing  node  that  is  mounted  in  front  line  combat 
vehicles,  such  as  the  M1A1 . 

The  army’s  approach  to  fighting  future  wars  has  identified 
preliminary  functional  requirements  for  that  vehicle  mounted  BMS 
node.  The  major  uncertainty  is  the  exact  timeframe  during  which 
major  steps  in  functional  growth  will  occur.  A  similar  statement 
can  be  made  for  the  fire  control  system,  which  will  also  require 
substantial  growth,  although  not  necessarily  at  the  same  times  as 
the  BMS. 

Although  the  M1A1  tank  is  a  large  vehicle,  there  are  significant 
limitations  in  the  availability  of  internal  turret  space  for 
stowage  of  additional  equipment  and  cabling.  A  considerable 
amount  of  engineering  will  be  required  to  even  integrate  a 
minimum  configuration  BMS.  The  problem  is  further  compounded  by 
the  likelihood  of  near  term  requirements  for  changes  in  other 
turret  subsystems,  due  to  factors  totally  unrelated  to  BMS. 
Finally,  it  is  clear  that  there  will  be  a  continued  need  for 
growth  in  system  capability  even  after  a  baseline  configuration 
is  defined  and  integrated. 

With  these  factors  in  mind,  it  is  important  that  design  changes 
being  planned  For  the  M1A1  FCS  and  BMS  consider  the  totality  of 
the  requirements  over  the  next  several  years.  The  traditional 
growth  path  in  combat  vehicle  electronics  systems  has  emphasized 
"self-sufficiency”  in  new  functions  in  order  to  simplify  integra¬ 
tion  and  minimize  impact  an  the  existing  equipment  designs.  Over 
a  period  of  time  and  a  number  of  changes,  however,  this  ulti¬ 
mately  leads  to  an  unacceptable  proliferation  of  electronics 
boxes  and  complex  interconnects. 

The  M1A1  turret  is  at,  or  very  near,  the  saturation  point  for 
integration  of  major  new  electronics  subsystems.  Thus,  more 
emphasis  must  be  placed  on  the  efficient  use  of  on-board  sensors 
and  electronics.  This  may  require  redefinition  of  some 
traditional  subcontractor  roles  and  the  replacement  of  some 
equipment  that  meets  current  needs  but  has  no  inherent  flexibil¬ 
ity  or  growth  capability. 

This  study  examined  the  relationship  of  BMS  and  FCS  and  the 
probable  design  impacts  of  Functional  and  performance  growth  in 
these  areas.  It  concluded: 

Cl)  the  on-vehicle  BMS  and  FCS  functions  are  closely  inter¬ 
related,  requiring  similar  computational  capability  and 
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data  Flow; 

the  potential  exists  For  data  sharing  between  the  BfIS 
and  FCS  functions,  which  could  lead  to  elimination  of 
some  of  the  current  fire  control  equipment  without  loss 
of  performance; 

bath  the  BUS  and  FCS  will  experience  substantial  growth 
that  is  primarily  cantered  on  increased  "intelligence” 
(computational  capability 3  rather  than  the  addition  of 
more  sensing  hardware. 

Because  of  this,  it  is  important  that  vehicle  related  BUS  and  FCS 
issues  be  addressed  as  a  single  problem.  This  report  recommends 
that  a  development  be  undertaken  for  an  integrated  FCS/BhS 
processing  and  control  system,  and  that  it  address  the  FCS 
impacts  of  armament  and  armor  enhancement  as  well  as  the  near 
term  BUS  functions.  It  also  recommends  that  the  new  processor 
system  be  based  on  standard  electronic  modules  and  nonproprietary 
architectures  that  can  be  procured  in  open  competition  and  are 
compatible  with  UHSIC  insertion. 

The  recommended  approach  may  not  be  compatible  with  the  current 
niAl  Block  II  production  schedule  objectives.  However,  this 
should  be  further  evaluated  in  terms  of  the  long  term  benefits  of 
a  more  orderly  transition  to  an  integrated  FCS/BMS.  That  analysis 
was  beyond  the  scope  of  this  study . 
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3.  BMS/FCS  REQUIREMENTS  AND  RELATIONSHIPS 


This  section  of  the  report  summarizes  the  specific  requirements 
for  FCS  and  BMS  operation  in  the  near  term  and  projects  the 
probable  areas  for  major  performance  and  interface  growth.  It 
also  discusses  the  equipment  required  to  accomplish  these 
functions  and  its  suitablility  For  growth. 

It  is  becoming  increasingly  difficult  to  categorize  and  assign 
responsibility  for  specific  functions  of  combat  vehicle  operation 
to  an  individual  subsystem.  The  sharing  of  data  across  tradi¬ 
tional  subsystem  boundaries  and  the  need  to  optimize  the  use  of 
on-vehicle  computing  power  will  make  this  division  of  responsi¬ 
bility  even  more  difficult  as  currently  planned  product  improve¬ 
ments  become  reality. 

Thus,  as  discussed  below,  the  assignment  of  specific  functions  to 
either  the  FCS  or  BMS  category  is  somewhat  arbitrary.  However, 
it  will  become  apparent  that  this  assignment  has  no  affect  on  the 
conclusions  of  the  analysis  and  is  merely  a  convenience  for  the 
purposes  of  communication . 

As  combat  vehicle  systems  become  more  sophisticated,  it  is  clear 
that  the  traditional  design  approach  of  subsystem  self- 
sufficiency  and  physical  separation  of  subsystem  designs  by 
functional  abjective  is  no  longer  economically  feasible  or 
required  from  a  technology  point  of  view.  Thus,  it  is  important 
to  view  the  control  and  communications  requirements  for  future 
vehicles  from  a  higher  level  systems  perspective,  and  to  re¬ 
examine  traditional  partitioning  of  the  system  functions. 

For  the  purposes  of  this  discussion,  however,  we  will  attempt  to 
associate  high  level  functions  primarily  with  either  the  Fire 
Control  System  or  the  vehicle  ’’node”  for  the  Battlefield  Manage¬ 
ment  System.  In  doing  this,  we  make  the  following  (somewhat 
arbitrary)  distinction: 

Fire  Control  (FCS)  functions  will  be  considered  to  be  those 
associated  with  the  detection,  identification,  and  engage¬ 
ment  of  individual  targets  on  the  battlefield  and  the 
measurement  of  vehicle  and  environmental  parameters  that 
affect  performance  of  these  functions. 

Battlefield  Management  (BMS)  functions  will  be  those  re¬ 
quired  for  consolidation  and  communication  of  tactical  data 
and  command  and  control  information  between  vehicles,  and 
for  the  timely  presentation  of  key  planning  and  status 
information  to  vehicle  commanders. 

It  should  be  noted  that  each  of  these  systems  is  both  a  source 
and  a  destination  for  data  that  is  indigent  to  the  other. 
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3.1  FIRE  CONTROL  SYSTEM 


The  firs  control  operational  requirements  can  bB  grouped  into  the 
following  basic  functional  elements  and  flow: 

w  Surveillance 

Sector  Search  ! 

I  i 

Target  Detection  and  Identification 

I 

i 

Classification 

IFF 

i 

—  Target  Selection  and  Designation  to  Gunner 

I 

Target  Cueing 

Prioritization  i 

1 

»  Engagement 

Target  Track/State  Estimation 
Weapon  Pointing  Computation 
Line  of  Fire  Control 

\ 

Damage  Assessment 


Each  of  these  areas  has  unique  requirements  and  distinct 
relationships  to  growth  issues  for  the  Ml  and  its  role  in  the  BMS 
system . 

Although  there  are  currently  no  formally  established  Fire  control 
system  growth  requirements  beyond  the  Commander’s  Independent 
Thermal  Uiewer  (CITY)  and  the  CDS  laser  rangefinder,  it  is  likely 
that  additional  requirements  will  be  established  before  1330. 

A  major  objective  in  Fire  control  evolution  must  be  to  extract 
the  greatest  benefit  from  BMS  and  the  equipment  inherently 
available  on  the  vehicle.  To  accomplish  this,  fire  control  will 
continue  to  demand  increasingly  significant  computational 
capability  at  the  vehicle  level.  This  is  driven  both  by  needs  for 
enhanced  performance  and  improved  supportability  with  minimum 
cost  impact. 

While  some  growth  will  occur  in  the  Form  of  new  sensors  and 
specific  hardware,  much  of  it  will  be  centered  on  extracting  more 
useful  information  through  additional  data  processing  and 
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consolidation  of  data  already  available.  Table  3-1  and  the 
following  paragraphs  summarize  the  current  and  near  term  FCS 
requirements  for  lilAl  along  with  the  probable  growth  paths  it 
will  take  in  the  long  term. 

For  the  purposes  of  this  discussion,  ’’Current/Near  Term”  will 
refer  to  capabilities  and/or  technologies  that,  from  a  cost/ 
schedule/requirements  point  of  view,  should  initially  be  in 
systems  fielded  under  the  M1P1  Block  II  program.  "Long  Term/ 
Growth”  refers  to  items  requiring  longer  development  that  are 
desirable,  but  not  essential,  to  an  operational  system.  It  is 
assumed  that  development  of  these  will  occur  at  some  point  in 
time,  and  that  consideration  for  their  ultimate  integration 
should  be  made  in  the  initial  system  architecture. 

3.1.1  SURUEILLPNCE 

The  surveillance  function  consists  of  scanning  pre-selected 
terrain  areas  for  potential  targets.  It  is  primarily  accomplished 
with  the  use  of  magnified  direct  view  optics  and/or  thermal 
imaging  sensors. 

3. 1.1.1  Current/Near  Term 

Surveillance  on  the  ni  and  tllftl  is  conducted  through  the  use  of 
open  hatch  observation  and/or  the  gunner’s  primary  sight  CGPS), 
which  has  both  direct  view  and  thermal  imaging  capability.  Sector 
search  with  the  GPS  is  accomplished  by  rotating  the  turret  in 
azimuth  Cto  which  the  GPS  is  mechanically  linked)  and  the  sight 
head  mirror  Cto  which  the  main  gun  is  slaved)  in  elevation. 

In  ■  recognition  of  the  need  for  high  performance  closed  hatch 
surveillance  independent  of  the  gun  system,  the  Block  II  M1A1 
will  also  integrate  a  second  viewing  device  -  the  Commander’s 
Independent  Thermal  Uiewar  CCITU) .  This  thermal  imaging  sensor 
can  be  controlled  independently  of  the  turret  and  provides  the 
capability  for  simultaneous  independent  surveillance  by  the 
commander  and  gunner  and  the  ability  for  continued  surveillance 
by  the  commander  while  the  gunner  is  engaging  a  target. 

Bath  the  GPS  and  the  CITO  lines  of  sight  are  controlled  by 
stabilization  and  control  electronics  which  normally  follow 
tracking  rate  commands  from  the  operator’s  control  handles.  The 
CITU  also  has  the  capability  to  automatically  scan  a  pre-defined 
sector  at  a  constant  rate  to  relieve  the  operator  of  the  need  to 
continually  command  the  line  of  sight  on  a  repetitive 
survei 1 lance  action . 

The  thermal  imagers  on  both  sights  currently  generate  non¬ 
standard  video  signals  for  displaying  the  scene  imagery. 

Interface  with  BhS 

The  primary  near  term  interface  of  the  FCS  surveillance  function 
with  the  BMS  will  be  to  provide  the  BF1S  node  with  the  vehicle’s 
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Table  3-1 .  Fire  Control  System  Functional  Requirements 


FUNCTION 

CURRENT /NEAR  TERM 

LONG  TERM/GROWTH 

SURVEILLANCE 

Manual  LOS  Control 

Manual  Saarch 

Block  II  Supplemented  by  CITV 
with  Simple  Auto-scan 

Automatic  Sector  Assignment 

High  Speed  Scan 

Adaptive  to  Intelligence  Data 
from  BMS  network 

TARGET  DETECTION 
&  IDENTIFICATION 

Manual  Operation  Using  Low/High 

Optical  Magnifications 

Block  II  Supplemented  by  CITV 

Automatic  Video  Target  Detection 

Automatic  Target  Detection  by 

Non- Imaging  Sensors 

Automatic  Target  Classification 

Automatic  IFFN 

Focal  Plane  IR  Imagers 

TARGET  SELECTION 
&  DESIGNATION 

Manual  Selection  by  Commander 

Automatic  Slew  of  GPS  to  CITV 

LOS  on  Command  (Block  II) 

Computer-Maintained  Multi-Target 

Queue 

Automatic  Adaptive  Prioritization  and 
Designation 

Capability  to  Insert  BMS-Oes 1 gnated  Targets 
Into  The  Vehicle  Target  Queue 

TARGET  ENGAGEMENT 

Manual  Tracking  -  Aided  by 

Stabl 1 Izatlon 

Automatic  Load  Computation  - 

Manual  Alignment,  Nominal  Ballistics, 
Linear  Target  Motion 

Automatic  Line  of  Fire  Control  - 
Offsets  ♦  Stabilization  ♦ 

Firing  Limiters 

Automatic  Target  Tracking 

Improved  Lead  Computation  - 
Automatic  Alignment/Zero,  Second 

Order  Kinematic  Lead 

Improved  Line  of  Fire  Control  - 
Adaptive  Stabilization  &  Firing 

Limiters,  Barrel  Dynamics 

DAMAGE  ASSESSMENT 

Manual  -  Using  High  Resolution 

Optics 

Assisted  By  Image  Processing  & 

Automatic  Target  State  Evaluation 

surveillance  sector  information.  This  would  be  used  primarilu  at 
the  platoon  command  level  to  control  and  monitor  surveillance  of 
the  assigned  sectors  of  responsibility. 

The  data  required  by  the  BMS  node  would  be  azimuth  orientation 
and  ranges  at  the  extremes  of  the  surveillance  sectors. 

3. 1.1. 2  Long  Term/Growth 

In  the  long  term,  the  selection  of  surveillance  sectors  and  the 
allocation  of  sensor  resources  will  become  more  automated.  In 
particular,  sector  scanning  will  be  computer  controlled  to  take 
advantage  of  automated  sensor  data  processing,  externally  derived 
intelligence  data,  and  knowledge  about  battlefield  lines  of  sight 
and  potential  areas  of  approach.  Additionally,  surveillance 
assignment  will  probably  be  coordinated  across  elements  of  one  or 
more  platoons  to  maximize  the  composite  surveillance  capability 
of  the  unit . 

From  a  line  of  sight  control  perspective,  the  impact  of  this 
surveillance  capability  on  the  fire  control  system  hardware  will 
be  minimal.  The  current  analog  control  and  stabilization 
electronics  will  be  adequate,  with  the  required  rate  commands 
being  generated  in  a  digital  processor. 

Interface  with  BMS 

The  surveillance  function  will  use  terrain  data,  vehicle 
position/heading  data,  and  sector  responsibilities/ target 
intelligence  transmitted  by  the  platoon  leader  through  a  BUS 
platoon  net  to  derive  the  required  control  commands  to  the 
sightCs) .  A  direct  command  link  from  the  BMS  to  the  line  of 
sight  CLDS)  control  function  in  the  FCS  will  exist. 

3.1.2  TARGET  DETECTION  AND  IDENTIFICATION 

Target  detection  occurs  when  an  object  of  potential  military 
significance  is  seen  in  the  surveillance  sector.  Depending  upon 
the  probable  nature  of  the  target  and  the  current  mission 
requirements,  additional  discrimination  is  usually  undertaken  to 
recognize  the  class  of  the  target  Ce.g.,  truck,  tank,  APC,  etc.) 
and/or  its  specific  type  Ce.g.,  T-72,  BMP)  befcre  further  action 
is  taken. 

3. 1.2.1  Current/Near  Term 

Currently,  target  detection  and  the  various  levels  of  ident¬ 
ification  are  accomplished  manually,  with  the  commander  or  gunner 
viewing  through  on-board  direct  view  optics  or  the  thermal 
imager.  Detection  of  possible  targets  usually  occurs  during  the 
surveillance  function  with  the  optics  in  a  wide  field  of  view 
mode.  Target  identification  is  accomplished  by  switching  the 
optics  to  a  higher  resolution  narrow  field  of  view  mode.  Both  the 
GPS  and  the  CITU  provide  the  required  sensing  capability. 


Implicit  in  the  identification  proceoe  being  diecueeed  here  is 
the  claself icetion  of  a  detected  target  on  the  battlefield  as 
friend,  foe,  or  neutral  CBIFF-N). 


The  primary  source  for  target  detection  is  the  thermal  scene 
image.  The  thermal  lmagera  in  the  BPS  and  CITU  develop  a  real* 
time  electrical  signal  (non-standard  video)  that  contains  all  of 
the  scene  data  currently  in  their  fields  of  view.  This  is  then 
displayed  on  CRT’s  for  observation  by  the  commander  and/or 
gunner . 

There  is  currently  no  provision  for  accepting  target  information 
from  off-vehicle  sources  other  than  by  verbal  location 
description  Cusing  landmarks,  etc.)  over  a  radio  net,  followed  by 
a  manual  search  and  detection  in  what  is  believed  to  be  the 
described  area. 

Interface  with  BUS 

The  only  near  term  interface  of  the  detection/ identification 
function  with  BMS  would  be  indirect.  The  ability  to  display  map 
and  target  information  via  the  BfIS  will  improve  a  commander’s 
apriori  knowledge  of  potential  targets,  but  he  will  still  have  to 
actually  detect  and  confirm  their  identity  manually.  This 
information,  combined  with  location  data  on  friendly  elements, 
could  also  provide  some  assistance  in  the  BIFF  function. 

3.1.2. 2  Long  Term/Growth 

The  mid-to-long  growth  in  this  area  will  be  to  automated  image 
processing  of  the  thermal  data.  The  ability  to  process  entire 
fields  of  view  in  a  fraction  of  a  second  and  automatically 
classify  and  cue  detected  objects  offers  the  potential  for  major 
improvements  in  the  rate  of  target  acquisition  and  the 
surveillance  sectors  that  can  be  effectively  covered  by 
individual  vehicles. 

The  major  technical  obstacle  to  incorporating  this  capability 
into  the  niAl  is  the  associated  computational  requirements. 
Recent  studies  by  firs  control  developers  have  concluded  that  an 
autocuing  capability  will  require  3  to  4  hops  of  scalar  and  45  to 
50  Mops  of  array  processing  throughput.  This  level  of  throughput 
capability  will  first  became  technically  feasible  for  combat 
vehicles  with  the  availability  of  WHSIC  processors  m  the  1987-83 
timeframe . 

Lessor  technical  impacts  would  also  occur  relative  to  the 
formatting,  distribution,  and  display  of  the  video  data.  The 
current  video  signal  format  is  not  compatible  digital  processing 
or  displaying  on  conventional  scanning  displays.  Thus,  the  signal 
would  have  to  be  scan  converted  and  distributed  in  real  time  to 
the  YH5IC  processor.  Formatting  the  processed  signal  and 
generating  symbolic  display  overlays  is  straightforward. 
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In  the  long  tmrm,  this  is  sn  srss  with  major  intsrfscs  to  ths  Bns 
function.  Ths  ability  to  slsctronically  locsts  and  classify 
targets  means  that  this  data  is  inherently  in  a  form  suitable  for 
automatic  computer  to  computer  commmunicatlon.  Thus,  specific 
target  information  from  individual  vehicles  could  be  auto¬ 
matically  consolidated  and  coordinated  at  higher  command  levels. 

Similarly,  target  information  from  off-vehicle  sources  could  be 
communicated  via  the  BMS  to  the  vahic.s  and  then  downloaded  into 
an  PCS  target  queue  for  processing. 

The  interface  to  the  BUS  will  be  straightforward  with  relatively 
low  data  rata  interchanges.  Basically,  target  position,  velocity 
and  classification  data  would  be  available  for  interrogation  or 
updating  by  the  BMS  as  new  date  is  developed. 

3.1.3  TARGET  SELECTION  AND  DESIGNATION 

In  the  modern  battlefield  environment  a  vehicle  commander  may 
have  to  choose  a  specific  target  for  engagement  from  among 
several  possibilities.  The  prioritisation  and  selection  process 
may  depend  on  several  factors,  including  mission  objectives,  the 
relative  threats  posed,  whether  a  target  la  already  being 
engaged,  ate.  Once  a  target  has  been  selected,  it  must  be 
designated  (handed  off)  to  the  gunner  and  acquired  by  him  for 
engagement . 

3. 1.3.1  Current/Near  Term 

Currently,  the  target  prioritisation  and  selection  process  is 
manual,  relying  on  the  observations  and  judgment  of  the  vehicle 
commander.  With  the  Ml  and  earlier  tanks,  target  handoff  is 
accomplished  by  manually  slewing  the  turret  until  ths  target  is 
in  the  gunner's  sight  field  of  view  and  can  be  observed  by  the 
gunner.  The  gunner  then  assumes  control  of  ths  gun  sight  'GPS) 
and  initiates  the  tracking  and  engagement  process. 

With  the  addition  of  the  CITU  to  the  niAi ,  the  designation 
process  is  automated  to  the  extent  that  the  GPS  can  be  auto¬ 
matically  slewed  and  aligned  with  the  CITU  lmi  of  sight  upon 
command.  Thus,  if  the  CITU  is  looking  at  ths  target  of  interest, 
the  target  can  be  quickly  handed  off. 

Interface  with  BUS 

In  the  near  term,  individual  tank  commanders  may  receive  target 
selection  guidance  from  their  platoon  leader  based  on  his 
assessment  of  the  consolidated  platoon  and  target  statws 
information.  However,  this  will  likely  initially  be  communicated 
through  the  BfiS  display,  with  no  automatic  interface  tc  the  FCS 

It  is  possible  that  a  control  interface  could  be  established  that 
would  slew  the  CITU  to  the  target  bearing  upor  request  from  tse 


vehicle  co—tndT .  Thie  would  require  a  mod  mg  and  control 
interface  with  the  BUS. 

3. 1.3. 2  Long  Term/ Growth 

In  the  long  tarn,  the  prioritisation  and  designation  function 
will  bo  assisted  by  the  autosstsd  isags  processing  described 
above  end  (possible  by  decision  support  software  (artificial 
intelligence)  integral  to  the  BHS .  Upon  completion  of  an  engage¬ 
ment  or  otherwise  becoming  available,  the  gunner's  sight  will  be 
autometically  slewed  to  the  bearing  of  the  next  highest  priority 
target  in  the  queue  for  that  vehicle. 

In  this  mode  of  operation,  the  CITU  does  not  have  to  be  aligned 
to  the  target  prior  to  handoff  and  therefore  it,  and  the 
commander ,  can  continue  with  other  functions  without 
interruption . 

The  design  impact  of  this  capability  is  relatively  minor.  It 
requires  computer  control  of  the  commanded  sight  rates  and/or 
control  of  the  reference  angles  for  the  deeignetion  loop  closure. 
Digital  processing  will  be  required  to  compute  the  reference 
angles  for  the  servo  loop  closure. 

Interface  with  BHS 

The  interface  for  thia  function  to  the  BMS  will  be  through  the 
target  queue.  The  BnS  must  have  the  ability  to  interrogate  and 
modify  the  contents  of  the  target  queue,  nodif ications  might 
include  the  insertion  of  new  targets  based  on  external  data 
and/or  changing  the  priority  of  targets  based  on  additional 
information  or  the  platoon  battle  plan. 

3 . 1  .  TARGET  ENGAGEMENT 

The  target  engagement  function  consists  of  the  Following  major 

elements 


Targst  Tracking  and  State  Estimation 
weapon  Pointing  Computation 
Line  of  Fire  Control 

Target  Tracking  and  State  Estimation  is  required  tc  establish  the 
position  of  the  target  at  the  time  of  firing  and  to  predict  where 
the  target  will  be  one  projectile  t ime-of -f i ight  in  the  future, 
weapon  Pointing  Computation  requires  prediction  of  the  ballistic 
displacements  of  the  projectile,  parallax  effects,  and  the  target 
displacement  during  projectile  flight  ? kinematic  lead-.  These 
effects  are  summed  to  produce  a  commanded  gun  angle  with  respect 
to  the  current  target  position 

Line  of  Fire  Control  is  the  function  tHat  physically  controls  the 
pointing  of  the  gun  at  the  time  of  project*. e  firing  It 
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generally  consists  of  two  major  elements  -  a  gun/turret 
stabilization  and  control  system  that  attsmpts  to  position  tha 
gun  sount  along  ths  commanded  anglss,  and  a  firing  limitsr  that 
iMprovss  upon  ths  basic  accuracy  of  ths  stabilization  system  by 
only  allowing  ths  projectile  to  be  fired  only  when  ths  servo 
error  is  small . 

3. 1.4.1  Current /Near  Tsrm 

Ths  current  architecture  for  ths  engagement  function  m  the  ni 
res  is  illustrated  in  figure  3-1.  although  this  does  not  reflect 
the  latest  technology  in  this  area,  it  must  be  noted  that  the 
current  performance  capabilities  of  the  ni  and  niAl  are  adequate, 
and  there  are  no  major  deficiencies  officially  designated  as 
requiring  correction. 

However,  requirements  and  design  studies  related  to  survivability 
improvement  for  main  battle  tanks  have  identified  probable  design 
changes  in  other  vehicle  subsystems  (particularly  armament  and 
armor)  that  will  adversely  affect  the  ability  of  the  current  FCS 
to  meet  its  performance  objectives  -  particularly  under  mobile 
conditions.  Also,  mission  requirements  for  ths  battle  tank  are 
evolving,  with  a  trend  towards  higher  performance  expectations  in 
this  function. 

The  probable  impact  of  these  on  the  current  FCS  configuration  is 
discussed  below. 

Target  Tracking  and  stats  Estimation 

Target  tracking  is  currently  a  manual  process,  with  the  gunner’s 
handle  displacements  being  sent  to  the  GPS  and  gun/turret  control 
electronics  and  interpreted  as  tracking  rate  commands.  Thasa 
rates  are  also  sent  to  the  ballistic  computer,  which  combines 
them  to  estimate  the  target  velocity.  Currently,  target  velocity 
effects  (kinematic  lead)  are  only  computed  and  compensated  m  the 
azimuth  channel . 

Any  upgrading  of  the  tracking  capability  of  the  system,  such  as 
linear  motion  compensation,  adaptive  handle  sensitivity  shaping, 
or  automatic  target  tracking  will  require  that  a  digital 
proceseor  use  control  handle  and  other  data  to  generate  the 
tracking  commands.  This  is  a  straightforward  design  modification 
that  should  be  part  of  any  FCS  design  change,  and  it  need  not 
affect  the  analog  sighthead  control  electronics  m  either  the  GPS 
or  the  CITU. 

The  referenced  near  term  survivability  improvements  will  '"ot  have 
a  first  order  impact  an  this  FCS  function. 

weSBpn_Po l nt i ng  Computet l on 

The  weapon  pointing  computations  currently  provide  fwl. 
continuous  update  compensation  for  ballistic  lead  and  parallax 
effects.  In  addition,  azimuth  target  velocity  is  estimated  from 
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tracking  commands  and  a  kinematic  lead  component  is  computed  in 
that  channel  to  compensate  for  target  motion  during  projectile 
flight. 


The  following  environmental  and  vehicle  parameters  are  measured 
or  estimated  and  compensated  for  in  the  equations:  Gun/ Sight 
Alignment,  Ammo  Zeroing  Adjustments,  Target  Range  at  Firing, 
Oehicle  Cant  (Static),  Apparent  Crosswind,  Air  Temperature,  Air 
Pressure,  Propellant  Temperature,  Static  Gun  Tube  Bend,  and  Gun 
Tube  wear. 

The  following  parameters  have  been  judged  to  produce  relatively 
minor  pointing  errors  under  most  conditions  and  are  therefore  not 
currently  compensated:  Target  Altitude  Differential,  Target  Speed 
in  Elevation,  Target  Acceleration,  Target  Range  Rate,  LOS 
Elevation  Angle,  Dynamic  Cant,  Dynamic  Barrel  Bend,  Latitude,  and 
Heading. 

Studies  ere  currently  underway  to  define  an  enhanced  armament 
system  for  the  niAl .  This  will  result  in  new  ballistic 
characteristics,  but  the  direction  will  likely  be  toward  reduced 
ballistic  sensitivity  and  therefore  place  no  new  performance 
demands  on  this  computational  process,  and  the  changes  can  be 
handled  by  changing  coefficients  in  the  ballistic  computer 
software. 

The  barrel  character let ice  of  an  enhanced  gun  will  probably  lead 
to  more  dynamic  motion  and.  consequently,  the  need  far  batter 
compensation  in  this  area  to  avoid  performance  degradation.  Part 
of  this  compensation  could  be  accomplished  by  automating  the 
barrel  bend  function  end  part  may  be  accomplished  in  the  line  of 
fire  control  function. 


Primary  control  end  positioning  of  the  line  of  fire  on  the 
currant  ni  systems  is  accomplished  by  different  means  in  azimuth 
and  elevation. 

Elevation  Channel.  -  The  elevation  control  function  is  illustrated 
figure  5-2 .  In  this  channel,  the  LOS  reference  to  the  target  is 
maintained  by  the  GPS  elevation  stabilization  system.  The  GPS  LOS 
angia  is  measured  by  a  resolver  which  is  electrically  chained  to 
the  gun  trunnion  resolver  and  then  to  a  digital  control 
tranformer  (OCT).  The  DCT  compares  the  gun  mount-to-LQS  angle 
with  the  commanded  angle  from  the  ballistic  computer  and  sends 
the  difference  to  the  GTD  as  a  position  error  signal  Tho  GTD 
continuously  commands  the  gun  elevation  drive  to  minimize  this 
error . 

The  basic  position  loop  for  sieving  the  gun  to  the  Cl  Tv  is 
similar  to  that  for  the  GPS.  «  resolver  chain  is  established  at  a 
different  frequency  from  that  of  the  GPS  chain,  and  it  linn  the 
same  gun  trunnion  resolver  with  the  CITu  elevation  resol-er  and  a 
Cl  TV- 1  inked  DCT. 


The  STD  uses  pressure  feedback  from  the  drive,  turret  pitch  rate, 
and  gun  rate  information  to  improve  its  dynamic  positioning 
accuracy  in  the  presence  of  terrain  induced  disturbances. 

To  further  improve  the  pointing  accuracy  at  the  time  of  firing, 
the  PCS  also  employs  a  "coincident  firing  window".  When  a  request 
to  fire  (trigger  pull)  occurs,  the  FCS  begins  monitoring  the  GTD 
position  error  level  and  does  not  allow  the  actual  firing  to 
occur  until  it  falls  below  a  preset  level.  This  has  the  effect  of 
producing  statistically  smaller  stabilization  errors  at  the 
instant  of  firing  than  can  ba  achisvsd  on  a  continuous  basis. 

This  function  is  likely  to  be  seriously  impacted  by  armament 
enhancements.  The  higher  performance  gun  will  result  in  poorer 
stabilization  performancs  due  to  a  number  of  characteristics, 
including  larger  inertias,  lower  mechanical  resonances,  higher 
static  and  dynamic  unbalance,  and  higher  dynamic  barrel  flexing. 

Some  aspects  of  this  problem  are  also  discussed  in  reference  5. 
The  preliminary  analyses  indicate  that  an  armament  upgrade  will 
probably  not  require  replacement  of  the  current  elevation  drives. 
However,  it  is  likely  that  major  changes  will  be  required  in  the 
control  laws  -  including  compensation  for  non-linear  hydraulic 
gain  and  acceleration  sensing  and  compensation,  additionally, 
barrel  dynamics  may  have  to  be  measured  and  integrated  into  the 
stabilization  and/or  precision  firing  control  logic. 

azimuth  Channel  -  The  azimuth  channel  for  line  of  fire  control  is 
substantially  different  than  that  in  elevation,  and  is 
illustrated  in  figure  5-1.  In  this  channel,  the  GPS  head  mirror 
is  fixed  to  the  turret.  As  a  result,  motion  of  the  sight  scene  in 
this  axis  is  controlled  directly  by  the  turret  motion. 

The  required  gun  offset  (lead)  angles  are  achieved  by  driving  the 
reticle  within  the  field  of  view  and  steering  the  laser 
rangefinder  to  follow  the  reticle.  The  servos  to  accomplish  this 
are  located  in  the  GPS  and  are  driven  by  commands  from  the 
ballistic  computer.  In  order  to  minimize  apparent  reticle  motion 
due  to  changing  lead  angles,  the  dynamics  of  the  turret  and 
reticle  motion  are  matched,  and  the  turret  is  counter-driven  with 
respect  to  the  reticle. 

The  position  loop  for  the  CITU  in  azimuth  more  closely  resembles 
the  GPS  elevation  loop.  Since  the  CITU  sighthead  assembly  has 
azimuth  freedom  with  respect  to  the  turret,  its  line  of  sight 
angle  can  be  measured  directly  with  a  resolver  and  used  in 
conjunction  with  a  DCT  to  slave  the  turret  in  azimuth. 

As  in  elevation,  additional  sensors  are  usad  to  improve  the 
dynamic  response  of  the  control  system.  In  this  case,  pressure 
feedback  from  the  azimuth  drive,  hull  turning  rata,  and  turret 
azimuth  rate  measurements  are  used. 

Because  the  gun  represents  a  relatively  small  part  of  the  total 


turret  inertia  in  azimuth,  the  use  of  enhanced  guns  will  not  have 
a  major  affect  on  this  axis.  However,  the  application  af  major 
new  armor  structure  could  have  a  significant  effect  -  principally 
due  to  larger  inertias  and  much  larger  unbalances.  This  may 
result  in  a  need  for  control  system  modifications  similar  to 
those  discussed  above  for  elevation. 

Interface  with  BtlS 

Interface  between  the  FCS  engagement  function  and  Bns  will  be 
minimal  from  a  control  perspective.  With  the  exception  of 
situations  where  BhS-suppiied  information  causes  the  engagement 
to  be  terminated  prior  to  target  destruction,  there  does  not 
appear  to  be  any  interface.  It  is  assumed  that  such  interruptions 
would  be  accomplished  manually  by  the  vehicle  commander  after 
being  so  advised. 

There  does,  however,  appear  to  be  the  potential  for  data  sharing 
between  the  two  systems.  In  particular,  the  same  vehicle  motion 
data  (angular  rates,  acceleration,  and  velocity)  that  is  used  for 
navigation  (position  location)  purposes  by  the  BhS  can  also  be 
used  for  control  and  stabilization  of  the  line  of  fire. 
Similarly,  heading  and  attitude  data  can  be  used  for  weapon 
pointing  computations,  thereby  eliminating  some  unnecessary 
sensor  redundancy . 

3. 1.4. 2  Long  Term/Growth 

Recent  analyses  of  the  high  stress  armor  battle  of  the  1990's 
have  identified  a  need  to  decrease  the  time  required  to  engage 
and  kill  a  non-cooperative  target.  Within  the  FCS  engagement 
function,  the  fallowing  are  the  most  likely  means  for  achieving 
this . 


Target  Tracking  and  State  Estimation 


Accuracy  of  the  current  system  is  limited  by  the  absence  of  a 
direct  position  error  measurement,  the  low  bandwidth  of  the 
gunner  as  a  tracking  controller,  the  limited  dynamics  of  the  hi 
azimuth  reticle  control  system,  and  the  effects  of  gunner 
jostling  under  mobile  conditions. 


Automatic  video  target  tracking  can  potentially  provide 
substantial  improvements  over  the  currant  levels  of  target  laying 
and  rate  estimation  accuracy.  In  addition,  estimates  of  target 
acceleration  can  be  derived  thereby  providing  a  basis  for  second 
order  kinematic  lead  prediction. 


Because  the  tracking  function  operates  on  only  a  small  part  of 
the  scene  image,  the  data  processing  requirements  for  auto- 
tracking  are  substantially  less  than  those  for  automatic 
detection  and  classification,  and  can  be  easily  handled  with 
currently  fielded  computer  technology. 
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The  implementation  of  two-axis  kinematic  lead,  including  target 
acceleration  effects,  will  be  straightforward  given  an  auto- 
tracking  capability. 

A  second  potential  growth  area  is  autozeroing.  In  this  process, 
the  actual  trajectory  of  projectiles  fired  by  the  system  are 
measured  in  flight  and  compared  to  the  predicted  trajectory.  The 
differences  are  compiled  over  all  rounds  fired  to  maintain  an  up- 
to-date  zeroing  correction. 

The  autozeroing  function  requires  a  separate,  although  somewhat 
simpler,  video  tracker  to  follow  the  projectile  in  Flight.  This 
may  become  an  important  function  in  the  near  future  because  of 
uncertainty  in  how  well  the  current  ’’fleet  zeroing’’  concept  will 
apply  to  both  the  M256  and  enhanced  weapons. 

Line  of  Fire  -  Control 

The  resolver  chain  position  referencing  system  is  well  suited  to 
the  current  line-of-sight  referenced  hi  FCS  and  its  mostly  analog 
electronics  control  system  functions.  However,  with  more  vehicle 
functions  being  digitized  and  the  potential  for  “off-vehicle” 
targeting  references,  this  is  becoming  a  less  desirable  approach. 

Additionally,  future  interfaces  with  BMS  will  cause  some  of  the 
FCS  control  functions  to  be  referenced  to  off-vehicle  coordinate 
systems  Ce.g.,  earth  or  UTM) .  Thus,  in  the  long  term,  the  current 
resolver  chains  will  be  replaced  with  loop  closures  internal  to 
the  digital  control  functions. 

Interface  with  BMS 

The  growth  elements  discussed  above  will  not  change  the  basic 
interface  to  the  BMS. 

3.1.5  DAMAGE  ASSESSMENT 

After  firing  at  a  target,  it  is  necessary  to  determine  if 
sufficient  damage  has  been  inflicted  to  allow  that  specific 
engagement  to  be  terminated. 

3. 1.5.1  Current /Near  Term 

Damage  assessment  is  currently  a  judgment  process  based  on 
manually  observing  the  target  after  firing.  When  available, 
observations  of  such  things  as  projectile  impact,  fire  and/or 
smoke  From  the  target,  sudden  changes  in  target  motion,  or 
apparent  lack  of  target  activity  provide  clues  for  judging  the 
effectiveness  of  the  shot  and  the  current  threat  status  of  that 
target . 

It  is  not  likely  that  this  Function  will  change  in  the  near  term. 


Interface  with  BUS 


There  Is  no  direct  interface  between  this  FCS  function  and  the 
BUS.  It  is  assumed  that  in  the  near  term  the  vehicle  commander 
will  manually  update  target  status  for  transmission  on  the  BUS 
net  when  time  permits. 

3. 1.5. 2  Long  Term/Growth 

Once  image  processing  and  automatic  target  tracking  capabilities 
are  implemented,  they  can  also  be  used  to  assist  in  the  damage 
assessment  function.  The  video  processor  can  analyze  explosions 
at  the  target  Ce.g.,  projectile  impact)  and  changes  in  target 
motion  and/or  shape  in  a  manner  similar  to  what  is  currently  done 
manually . 

In  many  cases  there  may  be  sufficient  information  in  the  video 
scene  to  give  a  high  degree  of  confidence  that  the  target  has 
been  disabled.  In  these  cases  the  FCS  may  automatically  disengage 
and  proceed  to  the  next  target  in  the  queue. 

The  video  processing  required  for  this  function  will  be  similar 
to  that  for  the  target  classification  function  and  will  require 
the  availability  of  UHSIC  technology. 

Interface  with  BHS 


Upon  termination  of  an  engagement  the  FCS  will  automatically 
update  the  status  of  the  target  to  reflect  the  probable  damage 
inflicted  and  remove  it  from  the  active  queue.  This  data  will  be 
sent  to  the  BMS  which  will  transmit  it  to  higher  command  levels 
as  appropriate. 


3.2  BATTLEFIELD  MANAGEMENT  SYSTEM 


This  section  discusses  key  characteristics  of  a  vehicle-based 
Battlefield  Management  System  node  and  its  interface  to  thB  FCS . 
The  BMS  can  be  viewed  as  a  communications  adjunct  to  the  current 
"self-contained"  target  acquisition  and  engagement  functions, 
which  are  mostly  grouped  under  the  general  heading  of  fire 
control.  Growth  in  BMS  will  focus  on  extending  the  consolidation 
of  intelligence  and  tha  interpretation  of  data.  The  vehicle- 
resident  BMS  will  ba  the  primary  "control”  source  for  vBhiclB 
status  evaluation,  external  communications,  and  Cwhere  appli¬ 
cable!)  platoon/company  and  higher  level  data  consolidation. 

In  its  initial  form,  the  BMS  will  focus  primarily  on  commun¬ 
ications,  reporting,  and  display  functions,  while  posessing  some 
capability  for  data  consolidation  at  key  command  levels.  However, 
future  application  of  AI  techniques  to  aid  in  the  interpretation 
of  data  and  response  planning  could  substantially  increase  future 
BMS  on-vehicle  computation  requirements. 

Current  M1A1  Block  II  requirements  call  for  a  basic  vehicle- 
integrated  Battle  Management  System  CBMS)  node  to  be  established 
as  soon  as  practical.  BMS  will  eventually  be  the  communications 
link  between  individual  vehicles,  and  Platoon,  Company  and 
Battalion  Commanders  in  the  data-linked  Maneuver  Force  Cref. 
Appendix  C) .  The  efficient  integration  of  all  of  these  levels  is 
a  difficult  task,  that  will  be  accomplished,  at  best,  aver  a 
period  of  several  years. 

Studies  have  been  conducted  by  the  user  community  to  determine 
what  functional  capabilities  are  most  important  in  a  BMS.  These 
studies  included  surveys  of  experienced  people  at  k'>y  command 
levels,  including  company  commanders,  platoon  leaders,  platoon 
sergeants,  and  wingmen.  Cn  a  consolidated  basis,  the  fallowing 
types  of  information  were  identified  as  being  most  important.  Tha 
elements  in  this  group  are  ranked  in  approximate  descending  order 
of  ranked  importance. 

Critical  Situation  Alert 
Concept  of  Operation 

Identification  Friend-Foe-Neutral  CIFF-N) 

Target  Distribution  &  Prioritization 

Heading  Reference  /  Navigation 

Call  For  Fire 

Battlefield  Geometry 

Command  Mission 

Reports 

Uehicle  Status 
Enemy  Weapons  Systems 

A  representative  interface  of  BMS  at  the  platoon  leader  level  is 
shown  in  Figure  3-2.  The  anticipated  distribution  of  BMS  nodes 
and  interfaces  at  other  command  levels  and  communications 
networks  are  shown  in  Appendix  C.  These  were  derived  from 


reference  1  and  are  reproduced  here  to  provide  a  useful  per¬ 
spective  . 


Figure  3-2.  BMS  Interface  to  Platoon  Leader 


In  order  to  view  thB  BHS  more  from  the  perspective  of  vehicle 
equipment  and  architecture,  it  is  convenient  to  group  the  oper¬ 
ational  functions  into  the  Fallowing  general  areas: 

Radio  Communication  Networks  Interface: 

Incoming  Messages : 

Receiving,  Ualidation  and  Routing 

Outgoing  Messages: 

Generation,  Routing,  and  Transmission 
Soldier  -  Machine  Interface: 

Display 

Operator  Inputs 
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Report  Generation 

Terrain,  Uehicle  &  Target  Reference 
Embedded  Training 
Decision  Support  Aids 

The  anticipated  requirements  in  each  of  these  functional  areas 
are  summarized  in  Table  3-2  and  discussed  in  more  detail  in  the 
remainder  of  this  section,  along  with  the  associated  fire  control 
interfeces . 

3.2.1  RADIO  COMMUNICATION  NETWORKS  INTERFACE 

The  communications  interface  function  consists  of  receiving  radio 
communications  from  other  BMS  nodes  and  formatting  and  trans¬ 
mitting  messages  to  other  nodes. 

3. 2. 1.1  Current /Near  Term 

In  the  near  term,  communications  with  other  BMS  nodes  will  be 
conducted  through  SINCGARS  radio  channels.  Automatic  encoding, 
decoding,  and  authentication  of  messages  is  required,  together 
with  automatic  frequency  changing  at  predesignated  time.  The 
function  must  also  provide  capability  to  preset  &  select  radio 
and  auxiliary  monitor  frequencies  through  the  operator  display. 

Interface  with  FCS 


It  is  anticipated  that  there  is  no  immediate  requirement  for 
direct  interface  between  the  FCS  and  the  BMS  radio  communications 
interface  function.  Other  BMS  functions  will  perform  the  routing 
of  data  to  and  from  the  FCS,  and  these  Functions  will  provide  the 
required  interface  to  the  communications  Function. 


3.2. 1 .2 


Long  Term/Growth 


Long  term  communications  interfaces  will  involve  more  sophis¬ 
ticated  encoding/decoding.,  larger  numbers  of  networks  and  inter¬ 
facing  nodes,  and  possibly  other  radio  equipment  interfaces.  The 
BMS  node  may  assume  the  identity  and  functions  of  other 
communication  systems  terminals  Ce.g.,  JTIDS),  and  provide  the 
vehicle  with  direct  external  communication  with  the  Maneuver, 
Fire  Support,  Intelligence/Electronic  Warfare,  Air  Defense  and 
Combat  Service  Support  elements. 


Interface  with  FCS 


The  long  term  direct  interface  of  this  function  to  the  FCS  will 
remain  as  described  above. 
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Table  3-2.  Uehlcle  BflS  Node  Functional  Requirements 


FUNCTION 


CURRENT /NEAR  TERM 


LONG  TERM/GROWTH 


COMMUNICATION  NETWORKS  Radio  Communication  by  Voice  Automatic  Decode  and  Message  Authentication 

INTERFACE'  Computer  Data  Link  to  SINCGARS  Automatic  Frequency  Changing  and  Network 

Automatic  Message  Alert  to  Commander  Coordination 

Automatic  Message  Encoding  Prior 
To  Transmission 

Automatic  Transmission  Routing 


SOLDIER/MACHINE 

INTERFACE 


REPORT  GENERATION 


TERRAIN.  VEHICLE.  & 
TARGET  REFERENCE 


Video  Display  of  Maps  and  Standard 
Overlays 

Incoming  Message  Display 
Menu-Driven  Command  Structure 
Message  A  Report  Composition  Capability 
Audio  Alerts 

Manual  Data  Entry 

Report  Formatting  Assist 

Radio  Transmission  of  Reports  Upon 

Command 


Digital  Map  Storage  (Limited  Area) 
Generation  and  Display  of  Tactical 
Map  Overlays 

Manual  Map  and  Terrain  Feature 
Analysis 

On-Board  Heading  Reference 
Interface  to  External  Position 
Location  Aids 


High  Resolution  Color 
Voice  Command  Input 
Helmet-Mounted  Display  Capability 


Automatic  Data  Consolidation,  Formatting 
and  Reporting 

Interpretation  of  FCS  and  Other  Sensor 
Data  for  Special  Reports 

Real-Time  Contact  and  Target  Status 
Update  Reports 

Extended  Map  Areas  and  Level  of 
Detal I 

Natural  Terrain  and  3-0  Representations 

Self-Contained  Navigation 

Automatic  Position  Update  and 
Reporting 

Automatic  Selection  of  Routes  of 
Travel 

Real-Time  Situation  Display 


_  EMBEOOED  TRAINING 


Operator's  Guides  for  BMS  Use  Extended  Operation,  Training,  and 

and  Maintenance  Maintenance  Support 

Interactive  Training  Capability 
Interface  With  Peripheral  Training 
Dev  I ces 


DECISION  SUPPORT  AIDS  None 


Integration  and  Automatic  Filtering 
of  Intelligence,  Fire  Support, 
and  Air  Defense  Networks 
Embedded  Data  on  Enemy  Weapon 

System  Capabl I Itles,  Doctrine,  and 
Tactics. 

Al-based  Situation  Analysis  and 
Tactical  Recommendations. 
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SOLDIER/MACHINE  INTERFACE 


The  soldier /machine  interface  Function  includes  tha  communication 
and  display  of  BMS-rolatad  information  to  tha  vehicle  operator 
(normally  the  commander) ,  and  tha  acceptance  and  interpretation 
of  commands  and  data  from  the  operator . 

3.2.2. 1  Current/Near  Term 

This  function  is  recognized  as  being  critical  to  tha  operational 
utility  of  the  BUS,  From  both  the  operator  interface/simpl lcity 
of  use  and  vehicle  integration  viewpoints.  Studies  to  data  have 
focused  on  the  need  for  a  multi-function  interactive  control  and 
display  capability  that  is  integrated  into  a  single  graphics- 
oriented  device. 

From  a  user  point  of  view,  the  following  features  and  character¬ 
istics  have  been  identified  as  important  in  a  BUS  soldier/machine 
interface: 

Use  of  standard  military  graphic  symbols 
Minimized  alphanumeric  text;  maximum  use  of  graphics  and 
symbology 

Capability  for  symbology  overlays  to  maps  and  FCS  sights 

Digital  message  alert  and  display 

Full  color  map  display 

Free  text  (word  processing)  capability 

Draw  function 

Screen  Data  Input  (touch  screen  entry) 

Uiewable  unbuttoned  (hatch  open) 

The  simultaneous  display  of  alphanumerics,  symbology,  and  terrain 
maps  is  essential  to  effective  man-machine  communications.  Color 
display  is  also  desirable  because  of  its  inherent  efficiency  far 
information  presentation,  but  the  required  functions  could  be 
performed  with  a  multiple  gray  scale  monochrome  display  (8  shades 
are  desired  as  a  minimum) . 

The  bulk  of  the  critical  information  display  is  envisioned  as 
being  map  and  symbology  oriented,  and  should  include  the 
flexibility  and  capabilities  of  traditional  ’’paper  map” 
approaches,  such  as: 

Display  of  essential  standard  map  features  (contour  lines, 
roads,  vegetation,  towns,  water) 

Display  rotation  and  orientation  (similar  to  rotating  a 
paper  map)  to  help  individual  tank  commanders  maintain 
orientation  while  navigating  their  vehicle. 

Standard  military  graphic  overlays  (operations,  fire 
support,  enemy,  and  engineer/obstacle) ,  and  selectable  map 
scaling . 


Selective  display  or  highlight  capability  to  allow  oparators 
to  manually  dim  or  bnghtan  specific  overlays  ie.g.  grid 
lines,  numbers,  etc). 

The  operator  input  must  be  simple  and  highly  flexible,  with  the 
capability  for  accepting  both  text  and  graphical  information  it 
must  support  the  rapid  entry  of  data  required  to  recall,  create, 
and/or  communicate  to  other  vehicles  any  of  the  displays 
described  above.  A  touch  sensitive  display  screen  approach 
appears  most  suitable  for  direct  actuation  of  software-selectable 
control  choices  and  rapid  placement  of  symbology  on  overlays. 

Other  requested  hardware  features  include: 

8”  diagonal  screen  minimum  ("The  Bigger,  the  Better”) 

SIS  x  SIS  pixel  resolution  minimum 

Simultaneous  display  of  alphanumerics,  symbology  and  terrain 

maps 

Repositionable  display  to  allow  viewing  and  interaction 
from  inside  the  turret,  popped  hatch  mode,  and  chest  out 
operation . 

Capablity  of  accepting  a  peripheral  printer  to  copy  text  and 
graphic  overlays. 

As  will  be  shown  in  the  technology  discussion,  the  totality  of 
this  desired  functional  capability  is  difficult  to  achieve  with 
currently  available  equipment. 

Interface  with  FCS 

It  is  envisioned  that  the  BHS  soldier /machine  interface  will  be 
multi-purpose,  providing  a  direct  interface  with  the  fire  control 
system  as  wall.  The  FCS  interface  will  include  control  panel  type 
functions  (including  FCS  moding  and  target  designation >  and  the 
display  of  alerts  and  important  status  information.  However,  if 
the  display  interface  to  the  external  system  uses  standard  video 
formats,  this  display  Function  might  also  serve  as  a  back-up  far 
real  time  display  of  sight  imagery. 

3 .2.2.8  Long  Term/ Growth 

Continuing  technology  improvements  in  video  display  will  provide 
smaller  packages  with  higher  resolution  and  color  display  of  BffS 
information  to  aid  operator  discrimination.  uoice  activated  data 
input  and  helmet-mounted  displays  are  other  future  growth  areas. 


3.2.3  REPORT  GENERATION 

One  of  the  major  obj active*  of  th>  BUS  i*  to  nl iivi  the  over  — 
atmaad  tank  commander  of  repetitive  and  time  consumma  tasks 
while  improving  overall  communications.  Time-sansi t 1 va  and 
critical  situation*  era  whan  status,  tactical,  and  logistical 
reports  are  needed  the  most  bw  higher  command  levels,  but  this 
reporting  seldom  occurs  in  a  timely  fashion  now  because  the 
situstlon  at  hand  requires  so  much  attention  from  the  individual 
vehicle  commander . 

3.2.3. 1  Current/Near  Term 

Reporting  is  currently  manually  performed  by  voice,  radio  or 
wire,  and  written  communications.  Table  3-3  summarizes  the 
standard  reports  and  orders  planned  for  handling  by  the  BUS.  The 
operator  must  be  able  to  compose,  recall  previous  reports,  edit 
for  updated  information,  retransmit  and  save.  Reports  will 
probably  be  generated  by  the  use  of  menus  rather  than  keyboard, 
and  will  be  closely  tied  to  the  terrain  map.  BnS  reports  will 
incorporate  graphic  overlays,  symbology,  terrain  mapa,  locations, 
ranges,  directions,  free  drawings  and  text  as  appropriate. 

igtirfisf  t e  fcs 

The  primary  FCS  interface  will  be  for  reporting  and  FCS  status 
information  of  targets.  The  BflS  will  allow  manual  operator  entry 
of  location*  of  targets  (acquired  through  FCS  sighting  devices) 
via  touch  screen  overlay  to  a  digital  map.  An  alternative 
approach  can  be  to  pass  LOS  direction  and  target  range  data 
directly  from  the  FCS  to  the  BfIS.  From  either  of  these  inter¬ 
faces,  the  Bns  can  automatically  calculate  grid  coordinates, 
straight  line  distance,  and  direction  from  the  vehicle  to  the 
target .  This  data  will  then  be  automatically  inputted  into  a  spot 
report . 

Logistic  data  (e.g.,  ammunition  remaining)  and  equipment  status 
(From  BIT)  will  also  be  extracted  From  the  FCS  For  reporting 
purposes . 

3. 3. 3. 2  Lang  Term/Growth 

New  techniques  oF  abbreviated  reports  will  be  developed  where 
much  oF  the  inFormation  is  automatically  acquired  by  the 
integration  oF  mtemal/externai  systems.  Automatic  reporc 
consolidation  will  occur  at  diFFerent  levels  -  Platoon  leader 
combining  reports  From  individual  tanks;  company  commanding 
aFFicar  From  platoon  leaders,  etc.  Additional  sensor  data  From 
various  subsystems  will  be  integrated  For  composite  situation 
reporting.  For  example,  by  integrating  data  From  the  wind  sensor, 
NBC  alarms,  navi  gat  ion  system  and  Future  analysis  programs, 
downwind  NBC  reports  can  be  automatically  generated  and 
transmitted . 
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Table  3-3.  Battlefield  Management  Reporta 


Operation  reports 
Spot  report 
Situation  report 
Contact  report 
Bridge  report 
Cross  report 
Route  recon  report 
Obstacle  report 
Bypass  report 
StanO-to  report 

Intelligence  reports 

Sensitive  I  teas  report 

Prisoner  of  oar  (PM) /Captured  enter  I el  report 
Military  Intelligence  Jaeelng  Interference  report 
(MlJl  report) 

Logistics  reports 

Equlpaent  status  report 
Battle  loss  spot  report 
Aopo  status  report 
Aaao  reguest 
POL  status  report 
POL  request 


Personnel  reports 

Personnel  battle  loss  report 
Medical  evacuation  request 

NBC  reports 

Observers  I  nits  I  report 

I  anted  I  ate  warning  of  expected  contselnatlon 
Radiation  dose-rate  report 
Areas  of  contselnatlon  report 

Warning  Order 

Operations  Order 

Fragmentary  Order 
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Interface  tg  FC3 


FC3  will  be  integrated  with  BHS  to  provide  automated  passing  of 
derived  target  data  for  screen  and  report  update.  Contact 
reporta  will  be  eutoeeticallu  transmitted  when  a  tank  lasas  and 
Fires.  Image  processed  “ snapshot ”  pictures  of  Cl  To  views  could 
also  be  incorporated  into  reports  for  intelligence  purposes  and 
further  analysis. 


3.2.4  TERRAIN,  UEHICLE  ft  TARGET  REFERENCE 

This  function  provides  the  relationship  of  the  combat  vehicle  to 
the  surrounding  environment  by  maps,  friendly  and  enemy  unit 
positioning  and  statue,  and  target  classification  (including  iff) 
and  prioritization  data. 

3.2.4. 1  Current /Near  Term 


The  BHS  must  carry  an  on-board  data  base  (50  x  50  sq.  km  desired) 
of  digital  map  data.  This  will  include  key  features,  such  as: 
Contour  lines.  Roads,  Uegetation,  Towns,  and  Water.  The  data 
equivalency  of  detail  found  on  the  standard  map  scales  of 
1 : 250 , 000  ( 30km  x  30km);  1:50,000  C6km  x  6  km);  and  1:25,000 
(3km  x  3km)  will  be  available.  Table  3-4  summarizes  the  infor¬ 
mation  content  of  these  map  levels. 


Selectable  overlays  of  Friendly  units,  Enemy  units,  Obstacles, 
contour  lines,  grid  lines,  LOS  and  Assigned  sectors  will  be 
available  to  allow  the  tank  commander  to  individually  tailor  his 
terrain  display. 


This  function  must  also  generate  the  required  vehicle  position 
and  heading  information  from  a  combination  of  on-board  equipment 
and  external  (radio-linked  devices). 


Interface  to  FCS 

By  providing  overlays  of  LOS  and  assigned  sectors,  important 
relationships  can  be  visually  interfaced  between  BHS  and  FCS 
functions  for  the  tank  commander.  Battlefield  Identification 
Friend  or  Foe  (BIFF)  will  provide  data  to  reduce  the  chance  of 
firing  on  a  target  that  is  friendly,  and  prevent  firing  on  a 
target  that  has  already  been  observed  by  another  source  as  out  of 
action . 


By  displaying  the  distribution  of  targets  sighted  by  other 
elements  as  an  overlay  to  a  digital  map,  BflS  can  calculate 
straight  line  distance  and  headings  for  hand-off  to  the  FCS  upon 

command . 

Terrain  analysis  prior  to  formulating  an  operational  plans  will 
be  manual,  but  will  utilize  digital  mapping  and  communication 

features  for  access  of  other  data  bases. 
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3.2.H.2  Long  Term/Growth 


On-board  digital  tarram  map  atoraga  will  ba  mcraaiad  c  to  100  x 
100  aq.  k«),  with  continuoua  zoo*  and  scroll  features. 

Tha  situation  display  will  ba  axpandad  to  includa  natural  tarram 
and  3-0  raprasantat ions  (l.a,  salact  a  location  on  tha  tarram 
map  and  than  viaw  that  araa  in  -  dimensional  parpective  for 
weapon  for  waapon  placement , ate . ) .  It  will  also  provida  raal  time 
display  of  position  and  location  of  ona's  own  vehicle,  unit, 
highar  units,  enemy,  and  adjacant  units  by  mtagration  of 
intarnal  navigation  and  haading  rafaranca  information  with  targat 
information  from  axtamal  sensors . 

There  may  ba  application  of  Artificial  Intelligenca  software  to 
perform  terrain  analysis  and  route  selection  t  display,  with 
additional  detail,  tha  BMS  may  also  provida  capability  for  a 
Mounted  Operation  m  urban  Terrain  (M.Q.u.T.),  showing  specific 
built  up  areas  and  consecutive  overlays  of  each  building  story 
and  subtarrain  level . 

3.2.5  EMBEDDED  TRAINING 

As  tha  complexity  of  tha  combat  vehicle  increases,  continued 
training  and  simulation  of  battle  conditions  is  critical  to  force 

readiness . 

3.2.5. 1  Current /Near  Term 

An  embedded  training  function  must  include  access  to  vehicle  mass 
storage  of  such  documents  as  the  5ystem  Operators  Guide,  How  to 
Fight  Manual  far  BMS  operations,  and  Maintenance  Manuals.  This 
BMS  function  should  be  able  to  conduct  interactive  tactical 
training  scenarios  (display  lifelike  targets  m  FCS  and  Bns 
displays),  for  individual,  collective  and  unit  training 
exercises . 

Interface  to  FCS 

Interface  to  the  FCS  in  the  near  term  is  expected  to  be  primarily 
manual.  Interface  to  the  FCS  displays  will  ba  desirable  for 
situation  simulation. 


3. 2. 5. 2  Long  Term/Growth 

Extended  and  enhanced  operational,  training  and  maintenance 
support,  including  decision  support  aids. 


Table  3-«*.  Terrain  nap  Featuraa  (Page  l  of  2) 


1  >290.000  TERRAIN  NDP 

Cbwti  XliiXta  nt 

Canton p  1 1  ms  wltb  •••nation  m^ors 

Tom/c I  ties  (»ol  la  black  shape  out  I  Inlag  tho  built  up  ar*a) 
Vofotetlon 

Motor  (r I *ers,  lafcos,  large  ponda.  large  stroaos) 

Airfields 
0*1 iroaOa 

Ail  prloory,  hart  surfaco.  all  weather  roaat 
(Aedbalis) 

All  secondary,  Kara  surtaoa,  all  naathar  roaMa 
(Caodystrlpoa) 

0oaM  hunters 
Tohn  nanea 
Motor  MOM 
•ridges 

1:90.000  TERRAIN  MAR 

Conor*  MiaiK*  araa 
Contour  llnoa  with  •  I  ««at  I  on  mmNti 
Town/c I  ties  (Individual  bull  dints) 
v«t«tatton 

Motor  (rivers,  lafcos,  ponds,  stroaao,  swaaps,  ear shy  aroas) 
AlrttolO*  and  airstrips 
Ra  1 1  roods 
Roads 

All  Recalls 
A l I  Candy strip** 

All  light  duty  all  wether,  hard  or  laproved  surfaco 
rood*  and  falr/dry  weather,  un  laproved  surface  roads 
(MhlteOei Is) 

Road  nuafeers 
Town  naoos 
Matar  naoos 

Depressions,  cuts,  fill* 

Ouarrlos 
Power  1 1  nos 
Roglonal  features 

Straao  1  riser  ford  sites  (Korea) 

Rica  Paddies  (Korea) 

Vineyards  (PRC) 

Underpass  heights  (FR6) 

Bridges  with  weight  classifications 
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Tabla  3-4.  Tarrain  Map  Features  (Page  5  of  2) 


1 >29,000  TERRAIN  MAP 

Covars  3  Ka  x  3  Ka  area 

Contour  Knot  with  elevation  nuabors 

Building*,  Towns,  cltlos  (oxtrsao  dotal l) 

Vegetation 

Nartor  <r  Ivors,  lakes,  ponds,  stroaas,  swoops,  oar  shy  areas) 

Airfields  and  airstrips 

Railroads 

Roods 

All  Redbal Is 
All  Candy  sir  I poa 
All  Whttebal Is 
All  trails 
Rood  nuabors 
Town  naaos 
Motor  naaos 

Ooprosslons,  cuts,  fills 
Quarries 
Power  linos 
Regional  features 

Stroea  t  rlvor  ford  sites  (Korea) 

Rice  Paddles  (Korea) 

Vineyards  (FRO) 

Underpass  heights  (FRG) 

Bridges  with  weight  classifications 
6as  stations,  fuel,  POV  reserves 

Type  vegetation  (scrub,  orchards,  nursery,  evergreen, 
deciduous) 

Identification  of  how  aany  stories  a  building  Is  and  If  It 

has  a  cel  lor 
Subways 
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3.5.6  DECISION  SUPPORT  AIDS  (Future  Requirement) 

By  application  of  artificial  intelligence  techniques,  data  on 
embedded  Soviet  weapon  system  capabilities,  doctrine  and  tactics, 
and  integration  with  Intelligence  networks,  Fire  Support  net¬ 
works,  and  the  Air  Defense  Artillery  network,  decision  support 
aids  could  be  developed  to  assist  the  tank  commander  in  under¬ 
standing  the  battle  situation  and  the  probable  effects  of  his 
potential  actions. 

This  is  a  long  term  objective  which  will  have  substantial  inter¬ 
face  with  all  of  the  on-board  systems.  However,  the  nature  of 
that  interface  is  not  definable  at  this  time. 
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4.  KEY  TECHNOLOGIES  AND  STANDARDS 

The  selection  of  an  architecture  For  M1A1  FCS/BMS  is  highly 
dependent  upon  the  current  and  projected  availability  of  key 
processing,  interface  and  communication  technologies,  and  their 
compatibility  uiith  equipment  already  in  the  system.  This  section 
summarizes  the  current  technology  in  areas  of  specific  concern  to 
this  application. 

4.1  DIGITAL  PROCESSING  TECHNOLOGY 

The  availability  of  computer  processor  elements  using  ULSI  and 
UHSIC  technology  provide  considerable  flexibility  in  processor 
design,  including: 

o  Bit-slice  building  blocks,  which  can  be  used  to  configure 
a  processor  to  unique  requirements. 

o  Fixed  architecture  commercially  available  microprocessor 
and  microcomputer  circuits. 

o  Custom  ULSI  and  UHSIC  processors  designed  to  a  specific 
architecture. 

The  bit-slice  approach  has  been  applied  in  many  diverse  military 
processor  applications.  Typically  bit-slice  computers  require  a 
significant  number  of  ’’glue  chips”  to  complete  a  function.  High 
speed  processors  can  be  developed  and  integrated  into  complex 
architectures  using  this  technology.  The  penalty  associated  with 
this,  however,  is  generally  increased  3ize  and  power  require¬ 
ments.  When  compared  to  ULSI  and  UHSIC  technology  processors, 
the  greater  number-  of  components  required  to  build  a  Bit-slice 
processor  also  increase  life  cycle  costs. 

Commercially  available  processors  and  microcomputers  offer  a 
significant  cost  advantage  at  the  component  level  over  custom 
hardware.  However,  the  lack  of  fixed  standards  (For  example, 
17S0A  Instruction  Sat  Compatibility)  and  the  issue  of  long  term 
availability  of  candidates  within  this  group  makes  this  family  of 
processors  generally  undesirable  for  application  in  production 
military  equipment.  As  with  the  current  fll  computer,  large  chip 
inventories  must  be  established  during  thB  limited  production 
life  in  order  to  assure  long  term  supportability  of  fielded 
equipment . 

The  final  and  most  technology  growth  oriBnted  category  For 
consideration  are  ULSI  and  UHSIC  processors  which  are  designed 
for  a  specific  user's  Ce.g.,  DOD)  architecture.  An  example  is 
the  MIL-STD-1750A  Instruction  Set  Architecture  which  has  bsBn 
implemented  in  both  ULSI  and  UHSIC  design  rules.  Both  approaches 
offer  substantial  advantages  over  more  traditional  MSI /SSI 
(Medium  Scale  Integration  and  Small  Scale  Integration) 
technology,  since  the  physical  features  sizes  are  substantially 
smaller  allowing  much  more  dense  components  to  be  developed. 
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Perhaps  the  greatest  single  benefit  derived  from  the  move  towards 
smaller  feature  size  is  a  corresponding  increase  in  processing 
speeds.  This  advantage  is  evident  when  UHSIC  is  compared  to  ULSI 
and,  similarly,  when  ULSI  is  compared  to  HSI/SSI.  Key  parameters 
for  the  three  technologies  are  compared  in  Table  4-1. 

The  differences  between  the  3.0  micron  ULSI  features  and  the  1.25 
micron  UHSIC  feature  geometries  not  only  yield  lower  power,  size, 
and  weight,  but  increase  speed  2  to  3  times.  The  smaller  UHSIC 
geometry  results  in  shorter  circuit  paths  which  enable  higher 
oscillator  Ctiming)  frequencies  as  well  as  fewer  chips.  Reducing 
chips  also  eliminates  the  number  of  buffers  that  are  required  to 
support  chip-to-chip  communication . 

Both  ULSI  and  UHSIC  designs  allow  single  board  computers  to  be 
packaged  as  Line  Replaceable  Modules  CLRM)  which  can  be  installed 
in  an  expandable  chassis  with  standardized  backplane  interfaces. 
Table  4-2  compares  characteristics  of  a  typical  MIL-STD-1750A 
processor  for  ULSI  and  UHSIC. 

ULSI  1750A  Processors 

The  single  board  ULSI  computer  can  be  procured  today.  In  this 
configuration  it  can  be  imbedded  as  a  Line  Replaceable  Module 
CLRM)  or  packaged  with  other  boards  to  provide  additional 
features.  The  single  board  ULSI  processor  can  be  obtained  with 
substantial  on-board  RAM  memory,  bus  interfacing,  or  other  types 
of  processing.  If  an  imbedded  concept  is  to  be  used,  however, 
standard  internal  communications  buses  must  be  defined  Csee 
Section  4 .2D . 

Application  of  CMOS  C Complementary  Metal  Oxide  Semiconductor) 
technolog  in  the  development  of  ULSI  chip  sets  has  provided  some 
significant  advantages  over' more  traditional  CMSI/SSI)  integrated 
circuit  technology.  Three-micron  features  allow  for  improved 
packaging  density,  particularly  with  the  development  of  com¬ 
paction  optimization  software  which  can  complement  a  standard  CAD 
design  to  increase  junction  densities.  The  application  of  these 
advanced  tools  has  resulted  in  the  development  of  chip  sets 
which  feature  Low  power  consumption  and  operation  over  the  full 
military  rated  temperature  range.  With  the  reduced  number  of 
components  and  interconnects,  it  would  seem  reasonable  that  the 
ULSI  computer  MTBF  will  be  much  higher  when  compared  to  more 
traditional  technologies. 

Taking  as  an  example  the  Delca  Systems  ULSI  chip  set,  a  total  of 
15  chips  C12  different  designs)  have  been  developed  to  support 
the  1750A  Instruction  Set  single  board  CPU  with  memory.  A  single 
board  1/2  ATR  card  is  available  which  can  provide  both  the  CPU 
and  192K  of  memory.  Control  features  built  into  a  custom  RCU 
CResource  Control  Unit  Chip)  allow  multiple  processors  to  share 
memory . 

This  design  uses  a  proprietary  bus  communications  interface,  but 
can  be  converted  to  a  standard  bus  once  internal  bus  standards 


Table  H-l .  Comparison  of  Processor  Circuit  Technologies 


TYPICAL  1750A  PROCESSOR:  SSI/MSI  VLSK*)  VHStC  . 

Parts  Count  43  I  0.6 

Size  8  1  t 

Weight  4  t  1 

Power  10  1  0.6 

Connections  5  1  0.6 

Speed  0.5  1  2-3 

Cost  5  1  1-1.5 

(*)  -  All  Values  Are  Normalized  To  VLSI  Technology. 

Table  4-2.  ULSI  and  UHSIC  Single  Board  1750ft  Processors 


VLSI 

VHSIC  PHASE 

Minimum  Throughput 
(DAIS  Floating 

Pt.  Inst.  Mix) 

1.0  MIPS 

3.0  MIPS 

Size  (SEM-E): 

Length 

Width 

Depth 

6.41  In. 

5.88  in. 

.58  In.  Max. 

6.41  In. 

5.88  In. 

.58  In.  1 

Power 

6.3  Watts 

3.8  Watts 

MTBF  (CPU  only) 

72,000  Hrs. 

(Greater) 

Feature 

Size  Requirement 

3  Micron 

1.25  Micron 

Component  Connect¬ 
ions  on  CPU  Board 

Low 

Very  Low 

Cost  (LCC) 

Low 

Low 

Clock  Speed 

6.25  MHz 

25  MHz 

Maintenance  Support 

2  Level 

2  Level 

Compatibility  With 
LRM/Expandab 1 e 
Chassis  Concept 

YES 

YES 

are  released.  Expansion  to  the  SEM-E  configuration  Csee  Section 
4.23  mill  allow  space  for  these  interface  chips.  It  may  be 
possible  to  interface  the  standard  ULSI  chip  set  with  the  UHSIC 
standard  bus  interface  chips  currently  being  developed  under 
government  contract.  This  would  eliminate  the  need  to  develop 
ULSI  standard  bus  interface  chips.  Figure  4-1  illustrates  the 
technology  transition  being  discussed  here. 

As  currently  developed,  these  15  chips  provide  a  full  1750A  CPU, 
complete  memory  and  input/output  interface,  and  a  comprehensive 
BIT  and  external  test  interface.  No  additional  ’’glue  chips”  are 
required.  The  substantial  reduction  in  components  yields  an 
estimated  HTBF  of  72,000  hours  for  the  CPU  and  29,000  hours  for 
the  CPU  with  memory  under  benign  conditions. 


VHSIC  Processor 


Figure  4-1.  Technology  Transition  -  ULSI  to  UHSIC 


UH5IC: 


Oevelapment  of  this  technology  has  basn  actively  supported  on  a 
tri-service  basis  through  the  UHSIC  Manufacturing  Technology 
Program  and  the  UHSIC  Technology  Insertion  Program.  The 
Technology  Insertion  Programs  supplement  thB  basic  technology 
research  programs  and  mere  established  to  assure  that  UHSIC 
development  would  have  practical  application  in  meeting  Defense 
Department  processing  needs  into  the  21st  century .  The  strategic 
importance  of  UHSIC  has  been  clearly  demonstrated  by  the  Pentagon 
supporting  its  tri-service  development  on  a  highest  priority 
basis . 

1750A  UHSIC  chips  built  to  Phase  I  standards  are  scheduled  for 
production  in  mid-1906,  with  modules  planned  for  limited  pro¬ 
duction  by  mid  1987,  and  full  production  of  modules  by  mid-1988. 

1750A  UHSIC  component  specifications  require  that  the  module  set 
meet  or  exceed  the  requirements  for  UHSIC  Phase  I  class  tech¬ 
nology  including: 

o  At  least  one  feature  size  Cor  junction  width)  of  1.25 
micrometers  or  less 

o  An  On-chip  clock  rate  of  at  least  25  MHz  Cunless 
performance  requirements  permit  relaxation). 

o  Operational  temperature  range  of  -55  C  to  +35  C  with  a 
goal  of  -55  C  to  +125  C. 

o  TTL  compatible  inputs  and  outputs,  where  appropriate 
o  Total  dose  -  5x10*4  rads  CSi) 

a  Transient/upset  —  10*7  rads  CSi)/S,  10  nanosecond  pulse 

a  Transient/permanent  damage  —  10*8  rads  CSi)/S,  10  nano¬ 
second  pulse. 

a  Neutron/permanent  damage  —  10*11  neutron/cm‘2  ,  1  MeU 

equivalent . 

UHSIC  Phase  2  component  specifications  decrease  the  feature  sizes 
to  .5  micron  and  increase  clock  rates  to  100  MHZ.  A  UHSIC  module 
may  consist  of  one  or  more  boards  controlled  by  a  single  control¬ 
ler  communicating  over  the  computer  communication  network. 
Examples  of  the  modules  under  UHSIC  development  which  have 
potential  for  application  in  the  Ml  include: 

1.  An  array  processing  module  for  processing  which  is 
relatively  data-independent ;  involving  real,  repetitive, 
generally  fixed-size  blacks  of  data. 

2.  A  complex  vector  processing  module  for  processing  which 
is  more  data-independent;  involving  complex,  repetitive, 


generally  fixed-size  blocks  of  data. 

3.  A  data  processing  module  for  scalar  processing  and  data- 
dependent  decision  making  (1750A  ISA). 

4.  A  memory  module  for  bulk  memory  storage. 

More  information  regarding  the  characteristics  of  these  modules 
may  be  found  in  references  S,  10,  and  11. 


4.2  ELECTRONICS  INTERFACE 


Electronics  interface  technology  is  a  major  factor  in  the 
complexity  of  the  architectures  of  modern  combat  vehicle  designs. 
Although  the  cost  and  performance  of  the  ’’intelligence”  in 
control  systems  have  improved  with  the  evolution  to  digital 
processing,  the  problem  of  interfacing  to  sensors  and  drive 


systems  has  become  more  complex  and  costly . 


The  need  for  much  greater  data  flout  within  future  systems,  such 
as  the  BflS ,  virtually  precludes  a  long  term  reliance  on  dedicated 
physical  hardware  for  individual  data  items.  Multiplexed  digital 
networks  can  provide  the  required  performance,  but  the 
communication  standards  and  the  technologies  for  interfacing  to 
the  external  world  are  still  in  the  early  stages  of  their 
evolution . 


This  section  reviews  the  interface  technologies  that  are  sig¬ 
nificant  to  the  fire  control  and  BUS  systems  that  could  be 
fielded  over  the  next  several  years.  Table  4-3  describes  elements 
of  the  interface  technologies  that  are  discussed  in  this  section. 


4.2.1 


DEDICATED  INTERFACES 


Combat  vehicle  electronics  systems  have  traditionally  been 
designed  around  star  type  architectures,  where  all  of  the 
required  data  flow  is  achieved  by  direct  point-to-point  wiring  of 
analog  signals  and/or  digital  logic  lines.  There  are  currently 
also  several  serial  digital  interface  standards  that  are  used  for 
direct  communication  between  digital  processors. 


Although  the  long  term  trend  for  combat  vehicle  system  architec¬ 
tures  is  toward  data  bus  communication  systems  Ce.g.,  Uetronics), 
systems  for  the  next  decade  will  continue  to  be  dominated  by 
dedicated  interfaces  and  their  associated  electronics. 


4. 2. 1.1  Analog  Interface  Electronics 


Analog  electronic  interfaces  occur  in  many  places  due  to  the 
inherent  analog  nature  of  most  sensors  and  actuators  currently  in 
use  on  combat  vehicles.  The  most  common  interfaces  are  dc  analog 
to  environmental  sensors,  oprator  controls,  and  power  drives, 
along  with  ac  analog  to  resolvers  and  synchros  used  for  angular 
measurements . 


4-6 


r  VV  V  V  "  +  , 


Table  4-3.  Electronic  Interface  Technolofliee 


acciNMics  |  onicE  |tecmolooy  |  PHium  |  wnat  |  un  |soo  hi  |*oh«*  |oorr  |Mdt*e 


A/D  Converter 

ILC  Dote  Device  Cor*. 

Ferranti  loot conduct  ar 
ZM447 

Micro  Meer  Sy iteo 

IT7444 

HykrlC  Syateu  Cor*. 
N»SI«-tf 

Hybrid 

CHOI 

Hybrid 

2*  *la  019 

12  bits 

•  bin 

•  bit 

lb  bit 

900  KMC 
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There  are  three  basic  approaches  to  interfacing  analog  inputs  and 

outputs  with  combat  vehicle  control  systems: 

Cl)  Analog  signals  are  routed  to  analog  servo  controllers 
and  computers,  and  servo  actuators  are  driven  via 
dedicated  analog  lines 

(2)  Analog  signals  are  routed  via  dedicated  wires  to  a 
digital  processor  and  converted  to  a  digital  format  for 
procsssing  within  the  module.  The  processed  information 
may  then  be  mads  available  to  other  computers  in  the 
system  via  digital  bus  or  dedicated  lines. 

In  a  similar  way,  the  control  command  values  are 
converted  from  digital  to  analog  format  at  the  processor 
and  sent  over  dedicated  lines  to  drive  the  actuator. 

(3)  Analog  signals  are  gathered  and  converted  to  digital 
format  near  the  source  and  are  made  available  to 
processing  elements  through  a  system  interconnect  bus. 

At  the  actuator,  a  module  attached  to  the  system  inter¬ 
connect  bus  converts  digital  signals  addressed  to  it 
into  analog  signal  formats  as  required  to  drive  the 
actuator . 

Analog  to  Digital  Converters  (ADCs) 

□n  tank  systems,  servo  controllers  require  sempling  frequencies 
of  no  more  than  approximately  500  Hz.  Currently  available  16  bit 
successive  approximation  ADCs  have  a  conversion  frequency  of 
about  10  KHz,  which  means  at  least  20  separate  analog  channels 
could  be  serviced  by  a  single  ADC. 

Thera  are  three  primary  methods  of  analog  to  digital  conversion 
applicable  here: 

(1)  Dual  Ramp  -  The  dual  ramp  converter  is  a  two  stage 

process.  Initially,  a  charge  proportional  to  the  input 
voltage  builds  up  on  an  internal  capacitor  over  a 
constant  time.  This  charge  is  then  bled  off  the 

capacitor  at  a  constant  rate  so  that  the  amount  of  time 

to  disharge  the  capacitor  is  proportional  to  the  total 
charge.  A  counter  times  out  the  discharge,  and  the 
value  on  the  counter  is  proportional  to  the  input 

voltage . 

This  method  is  inexpensive  and  very  accurate.  However  it 
is  also  extremely  slow  and  would  only  be  used  for 
signal  with  very  limited  dynarr^cs. 

C2)  Successive  Approximation  -  The  successive  approximation 
converter  consists  of  a  counter,  a  digital  to  analog 
converter,  and  an  analog  comparator.  Each  bit  of  the 
counter  is  independently  set  by  the  converter,  and  the 


output  of  t he  countar  is  sant  to  tha  DAC.  Tha  output  of 
the  DAC  is  compared  to  the  input  signal,  and  if  it  is 
greater  than  tha  input  voltage,  the  bit  being  tasted  is 
reset  to  0.  Working  from  the  most  significant  bit  to 
tha  least  significant  bit,  the  effect  on  the  test 
voltage  compared  to  the  input  voltage  is  made.  After 
the  least  significant  bit  is  tested,  the  counter  value 
is  passed  out  as  the  AOC  value. 

This  method  is  the  most  commonly  used  since  the  conver¬ 
sion  rate  is  relatively  high,  Cup  to  10  KK2  for  a  16  bit 
conversion)  it  is  moderately  priced,  and  has  a  high 
accuracy.  It  is  ideally  suited  for  the  degree  of 
accuracy  and  speed  necessary  for  the  servo  control  loops 
used  within  combat  vehicles. 

C3)  Flash  Converters  -  The  flash  converter  is  the  most 
expensive  method  of  doing  conversion  and  also  the 
fastest.  Essentially,  it  consists  of  set  of  analog 
comparators  and  a  precision  reference  voltage  with  a 
precision  voltage  divider  network.  The  outputs  of  tha 
comparators  are  sent  through  a  digital  encoder  to  give  a 
packed,  binary  value.  Each  voltage  step  to  be  sensed 
requires  its  awn  converter.  The  cost  rises  exponential¬ 
ly  with  precision  required.  For  an  8  bit  value  after 
conversion,  256  separate  comparators  are  required. 

The  Flash  converters  can  work  at  a  rate  of  up  to  20  HHz . 
They  are  typically  used  in  video  applications  where 
digital  signal  processing  is  required  on  video  signals. 
Except  for  this  case,  there  are  no  applications  in  the 
combat  vehicle  where  the  additional  cost  is  justified 
far  using  a  flash  converter. 


Digital  to  Analog  Converters  COACs) 

There  are  several  methods  for  digital  to  analog  conversion,  but 
the  most  common  method  weights  each  digital  bit  with  a  current 
proportional  to  the  value  of  that  bit.  The  currents  are  summed 
and  then  converted  to  a  voltage  output  level .  This  method  is 
accurate  and  the  speed  is  dependent  on  the  technology  used.  For 
example,  Honeywell  has  recently  released  an  8  bit  DAC  using  ECL 
technology  with  a  conversion  rate  of  200  MHz.  rtore  typically 
available  are  converters  using  hybrid  technology  which  have  12 
bits  of  accuracy  and  a  conversion  rate  on  the  order  of  100  KHz. 

Synchro  and  Resolver  Interfaces  : 

Synchro/resolver  technology  is  used  extensively  in  combat 
vehicles  for  angular  position  sensing  m  the  gun  and  sight  servo 
systems.  Both  synchros  and  resolvers  work  on  the  same  principle 
of  AC  voltage  transfer  between  a  rotor  and  a  stator.  The  stator 
is  a  fixed  shell  within  which  the  rotor  can  move  rotational ly . 
An  AC  reference  signal  is  sent  through  a  winding  on  the  stator, 
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and  an  AC  voltage  ib  generated  on  the  windings  of  the  rotor.  The 
rotational  position  of  tha  rotor  with  rapact  to  the  stator  is 
determined  from  tha  ratio  of  the  voltages  coming  from  tha  rotor 
windinga  to  the  rafaranca  voltage  at  tha  stator. 

A  synchro  has  throe  wires  coming  from  the  rotor  and  the  voltage 
between  any  two  wirea  has  a  defined  mathematical  transfer 
function  based  on  the  angular  position  and  the  reference 
f requencg .  A  resolver  has  two  pairs  of  wires  coming  from  the 
rotor,  tha  voltage  between  one  pair  being  proportional  to  the 
sine  of  the  rotor’s  rotational  position  and  tha  voltage  across 
the  other  pair  being  proportional  to  tha  cosine  of  the  rotational 
position.  The  servo  and  resolver  voltages  can  be  easilg  trans¬ 
formed  between  each  other  using  a  Scott  ’T’  Transformer,  and  so 
further  discussion  will  ba  limited  to  resolver  methodologies. 

Resolver  to  Digital  Converters  (RDCs) 

There  are  several  methods  of  resolver  to  digital  conversion, 
however  onlg  one  is  commonlg  used  in  commercial  RDCs.  In  the 
real  time  trigonometric  converter,  a  digital  counter  Cor 
successive  approximation  register)  generates  a  digital  value 
which  is  converted  to  a  sine  and  cosine  analog  value.  These 
values  are  then  combined  with  the  resolver  values  to  provide  two 
analog  signals  proportional  to  : 

cos CT)  sinCP) 

and 

smCT)  cas(P) 

where  T  is  the  angle  from  the  resolver  and  P  is  the  digital  angle 
from  the  counter.  The  analog  difference  of  these  angles  is  then 
generated,  producing  a  signal  proportional  to  : 

cosCT)  sinCP)  -  sin(T)  cos(P)  -  smCT  -  P)  . 

The  sign  of  this  value  then  determines  whether  to  increment  or  to 
decrement  the  digital  counter  Cor  set  the  bit  under  test  in  a 
successive  approximation  register).  This  loop  continues  until 
the  analog  value  is  nulled. 

Although  this  method  can  be  performed  in  a  continuous  fashion, 
the  common  method  is  to  sample  the  waveforms  at  the  peak  of  the 
reference  wave  and  hold  the  analog  values  of  the  reference  wave, 
the  sine  wave,  and  the  cosine  wave  so  that  the  conversion  can  be 
done  using  these  DC  values  rather  than  the  instantaneous  AC 
values.  Since  reference  frequencies  are  on  the  order  of  400  Hz, 
and  current  converter  technology  alliws  conversions  to  take  place 
on  the  order  of  10  KHz,  there  is  very  little  performance 
degradation  as  a  result  of  this  simplification. 


Digital  to  Resolver  Converters  (DRCs) 

The  digital  signal  to  be  converted  to  resolver  values  is  first 


split  into  a  quadrant  selector  and  then  the  trigonometric  value. 
The  first  two  bits  of  a  digital  value  determine  which  of  the  four 
quadrants  this  angle  is  in.  The  quadrant  determines  the  signs  of 
the  trigonometric  values  derived  from  the  remaining  bits. 

The  bits  for  determining  the  trigonometric  values  are  sent  to  two 
function  generators,  one  of  which  creates  an  analog  value 
proportional  to  the  sine  of  an  angle  between  0  and  SO  degrees, 
the  other  creates  an  analog  value  proportional  to  the  cosine  of 
an  angle  in  the  same  range. 

There  are  two  primary  ways  of  performing  this  conversion.  In  one 
method,  each  bit  in  the  digital  word  controls  a  switch  which 
allows  a  weighted  portion  of  the  reference  voltage  to  pass 
through  to  the  output.  This  weighting  is  done  either  through  a 
precision  resistor  network,  or  through  weighted  tapping  of  a 
transformer  coil  Cthe  reference  voltage  is  an  AC  signal). 

The  second  method  uses  a  ROM  or  similar  digital  lookup  table  to 
convert  the  digital  input  angle  to  its  digital  function  value 
Csine  or  cosine).  This  digital  value  is  then  sent  to  a  linear, 
multiplying  OAC  using  the  AC  reference  voltage  as  its  analog 
input . 

After  being  generated,  the  sine  and  cosine  values  are  inverted 
based  on  the  quadrant  selected .  These  two  values  are  the  final 
AC  signals  and  are  made  available  on  the  two  pairs  of  resolver 
1 i nes . 

4. 2. 1.2  Serial  Digital  Interfaces 

In  its  simplest  farm,  digital  communication  can  be  accomplished 
with  point  to  paint  logic  level  lines,  each  of  which  is  dedicated 
to  a  single  bit  of  data.  These  are  analogous  to  the  dedicated 
analog  interconnects  discussed  earlier. 

However,  digital  lines  can  also  be  easily  multiplexed  to  allow 
several  pieces  of  data  to  ’’time  share”  a  limited  number  of 
physical  lines.  The  standard  types  of  interfaces  include  serial 
and  parallel  links  either  of  which  can  be  dedicated  to  a  single 
interface  between  two  units,  or  support  multiple  units.  The 
characteristics  of  the  standards  most  suitable  for  combat 
vehicles  are  summarized  in  Table  4-4  and  ara  discussed  further  in 
the  remainder  of  this  section. 

RS232/449  Serial  Channel : 

The  EIA  RS232  and  the  RS449  standard  interfaces  are  both 
electronic  standards  which  define  the  interconnection  of  devices 
and  the  transfer  of  information  at  the  bit  and  byte  C8  bits) 
level.  Additional  encoding  or  protocol  must  be  defined  by  the 
user.  The  ASCII  character  code  is  the  accepted  encoding  practice 
at  the  byte  level,  but  for  higher  levels  of  protocol  in  a  network 
there  are  few  standards,  and  they  are  used  only  by  a  limited 
number  of  manufacturers. 
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These  interface  standards  have  been  in  use  for  years  and  are 
primarily  applied  where  data  transfer  rates  are  low  and  environ¬ 
ments  are  benign.  Both  are  serial,  unidirectional,  point-to- 
point  interfaces  that  operate  up  to  19.2  K  bits/sec.  The  RS232 
is  asynchronous,  relying  on  each  unit  to  maintain  its  own  clock 
and  the  relatively  short  distances  over  which  the  interface 
communicates.  Start  bits  indicate  to  the  receiver  register  to 
store  the  data,  and  stop  bits  indicate  the  end  of  message.  RS449 
has  the  additional  advantage  of  being  able  to  receive  both 
synchronous  and  asynchronous  information. 

Physically,  the  interconnect  consists  of  a  shielded  cable  with 
between  4  and  25  signal  wires,  depending  on  the  range  of  signals 
selected  for  use  from  the  standard  by  the  manufacturer. 
Connections  are  made  with  a  25  pin,  * □'  format,  subminature 
connector.  Since  a  separate  cable  must  be  provided  for  each 
communication  channel;  weight,  cabling  diameter,  and  connector 
space  can  become  significant  factors  when  there  are  many  commun¬ 
ication  channels  to  be  provided. 

The  RS232  channel  was  designed  primarily  for  the  transfer  of  text 
between  processing  elements  and  slow  terminals,  such  as  display 
screens,  character  printers,  and  modems.  This  channel  may  be  of 
use  in  dedicated  equipments  where  performance  is  not  critical  and 
the  environment  is  benign,  such  as  diagnostic  equipment.  However, 
its  slow  speed,  sensitivity  to  harsh  environments,  and 
restriction  to  point  to  paint  wiring,  make  it  a  poor  choice  for 
general  communication  in  a  combat  vehicle. 

RS422  Serial  Channel 

Like  the  RS232  interface,  the  RS422  interface  is  an  electronic 
interconnection  standard  which  does  not  specify  message  protocol 
beyond  the  bit  and  byte  levels.  However,  unlike  the  RS232 
standard,  the  electrical  specification  allows  the  R5422  to  be 
used  in  a  multidrop  configuration.  This  means  that  a  single 
trunk  line  may  be  used  to  interconnect  several  modules.  This 
capability  is  widely  used  in  industrial  networks  which  connect 
several  devices  in  a  proprietary  network  for  communication  and 
control . 

The  RS422  specification  calls  for  a  voltagB  differential 
electrical  signal  specification  across  two  shielded,  twisted 
pairs.  This  reduces  the  EMI  sensitivity  and  allows  longer  inter¬ 
connects.  An  RS422  cable  can  be  considerably  smaller  than  an 
RS232  cable  since  there  are  only  4  signal  lines  and  3  shields 
Ceach  twisted  pair  has  a  shield,  and  there  is  a  shield  over  both 
twisted  pairs).  Connections  can  be  made  with  smaller  connectors 
and  is  sometimes  done  with  Just  discrete  wire  terminators. 

Both  the  electronic  interface  and  the  cabling  for  RS422  commun¬ 
ications  are  inexpensive  and  readily  available.  This  interface  is 
already  available  on  some  military  equipment  that  may  find 
application  on  combat  vehicles.  For  example  Litton,  Kearfott,  and 
Honeywell  all  have  inertial  navigation  systems  with  an  RS422 
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interface,  and  R54S2  capability  haa  been  called  out  in  the 
Modular  Azimuth  Positioning  System  CMAPS)  requirement. 

This  communication  standard  could  be  very  useful  as  a  non- 
critical  communication  network  among  several  modules  where  single 
errors  won't  have  a  great  impact.  Gun  stabilization  and  tracking 
systems,  for  example,  both  require  continuous  data  transfer  at 
moderate  frquencies.  Isolated  data  errors  can  be  quickly 
averaged  out  of  significance,  or  -  can  be  subjected  to  a 
reasonableness  check  and  ignored. 

4.2.2  COMMUNICATIONS  NETUORKS  CDATA  BUS) 

The  dedicated  interface  technologies  discussed  above  typically 
provide  the  lowest  cost  interconnect  for  simple  systems.  Houiever, 
they  are  not  generally  compatible  with  system  growth,  and  quickly 
become  unwieldy  as  system  complexity  grows  and  multiple  digital 
processors  are  employed. 

Ulith  the  addition  of  BMS,  the  M1A1  tank  will  cross  the  boundary 
of  practicality  for  a  fully  dedicated  architecture  and  must, 
therefore,  consider  the  use  of  local  area  communications  networks 
for  some  of  its  intrasystem  communications. 

Two  levels  of  communication  are  addressed  in  this  section.  The 
first  is  the  system  level,  which  provides  the  external  connection 
of  electronics  boxes  that  are  physically  separated  in  the  system. 
The  second  level  is  that  of  the  internal  communications  within  a 
processor  assembly  (box) .  This  second  level  of  bus  communication 
will  be  significant  to  future  systems  with  the  planned  develop¬ 
ment  of  standard  electronic  Ccard  level)  modules. 

4. 2. 2.1  System  Bus 

The  physical  distribution  of  subsystem  electronics  units  around 
the  vehicle  together  with  their  related  data  transfer  require¬ 
ments  results  in  a  need  for  some  form  of  logical  interconnect. 
This  is  accomplished  through  communication  networks  which  have 
evolved,  as  systems  have  become  more  complex,  from  relative  iy 
straightforward  discrete  point-to-point  interconnects  to  sophis¬ 
ticated  multiplexed  data  buses. 

The  advantages  normally  associated  with  data  buses  are: 
o  Improved  reliability  (from  fewer  interconnects), 
o  Reduced  physical  unit  and  harness  sizes, 
a  Decreased  weight. 

There  are  certain  general  requirements  for  communications 
networks  which  must  be  met  for  any  system.  These  include: 

a  Reliable,  noise-free  communication. 


o  Data  transfer  rates  and  response  times  compatible  with 
the  functional/physical  partitioning. 

o  Minimum  subsystem  interconnect  cabling. 

o  Fault  tolerant  operation  without  single  point  failures. 

a  High  survivability  from  battle  damage. 

o  Reconfigurability  and  expandability. 

o  Compatibility  with  military  standards  to  allow  use  of 
existing  equipment. 

While  all  of  these  requirements  are  important,  compatibility  with 
existing  or  newly  emerging  standards  is  particularly  important 
for  a  number  of  reasons.  Through  logical  partitioning  of 
subsystem  modules,  a  new  system  can  apply  off-the-shelf  hardware 
designed  to  these  standards  without  major  impact  to  the  system. 
In  addition,  the  use  of  compatible  subsystems  and  a  standard 
communications  network  also  provides  other  potential  advantages, 
such  as: 

o  Reduced  time  and  expense  far  overall  system  integration 
and  validation 

o  Better  knowledge  of  the  failure  modes  and  effects 

o  Predictable  reliability  of  the  off-the-shelf  units 

o  In  many  cases,  an  established  parts  inventory  and  repair 
and  support  system. 

The  standard  communication  networks  which  appear  to  have 
potential  application  to  the  M1A1  FCS/BMS  system  are  discussed 
below  Cand  shown  in  Table  4-4D  . 

MIL-STD-1553/1773  Multiplex  Data  Bus 

This  military  standard  multiplex  data  bus  is  a  serial  bidirec¬ 
tional,  time  division  multiplex  bus  which  supports  multiple  users 
and  provides  a  well  defined  word  format  and  message  protocol. 
Time  division  multiplexing  is  the  transmission  of  information 
from  several  signal  sources  through  one  communication  system  with 
different  signal  samples  staggered  in  time  to  form  a  composite 
pulse  train. 

The  Mil-Std-1553  Bus  was  developed  to  reduce  the  complexity  of 
interconnecting  DOD  avionics  equipment.  It  has  gained  wide 
acceptance  as  a  standard,  and  there  are  numerous  military 
electronics  subsystems  designed  with  this  interface. 

It  operates  in  a  command/response  mode  with  one  active  bus 
controller  and  up  to  31  remote  terminals  on  a  single  self- 
clocking  bus  using  Manchester  II  bi-phase  encoding.  The 


nanchester  format  is  fairly  straightforward;  using,  for  a  logic 
one, a  bit  which  is  a  positive  level  (positive  voltage!'  on  the  bus 
for  the  first  half  of  a  bit  period,  followed  by  a  negative  level 
during  the  second  half  of  the  bit  period.  A  logic  zero  is  the 
exact  opposite. 

MIL-STD-1553  operates  at  a  1  mega-bit/second  rate,  and  uses  a 
high-  noise  immunity  transmitter/receiver  and  a  single  twisted 
shielded  wire  pair.  The  MIL-STD-1773  Bus  is  a  wide  band  fiber 
optic  cable  equivalent  to  niL-STO-1553  except  that  it  operates  at 
10  mega-bit/second  bit  rate.  Oue  to  the  higher  casts  For  inter¬ 
faces  and  limited  program  support  to  date,  ttIL-STD-1773  is  not 
commonly  used.  Besides  speed,  the  advantage  of  fiber  optic 
cabling  over  wire  is  that  it  is  excellent  in  environments  where 
Tempest  requirements  are  specified. 

The  multiplex  data  bus  functions  in  an  asynchronous  command/- 
response  mode  using  a  half-duplex  transmission.  The  bus 
controller  is  the  unit  responsible  for  the  information  flow 
coordination  on  the  data  bus.  It  controls  this  flow  of  infor¬ 
mation  by  transmitting  commands  to  one  of  the  remote  units  at 
predetermined  points  in  time.  A  bus  controller  may  be  a  stand¬ 
alone  microprocessor  based  unit  or  may  be  a  subset  of  the 
responsibilities  of  some  unit  designated  as  the  bus  controller. 
Current  electronics  technology  allows  the  packaging  of  two  dual- 
redundant  bus  controllers  an  a  single  1/5  ATR  or  larger  card. 

In  addition  to  coordinating  information  flow  on  the  data  bus,  the 
bus  controller  must  be  able  to  respond  to  changes  in  operational 
environment.  For  different  modes  of  operation,  responses  can  be 
worked  out  in  a  predetermined  manner.  For  unplanned  events,  such 
as  remote  terminal  failure  or  battle  damage,  the  bus  controller 
must  also  provide  the  capablility  for  detecting  the  resulting 
error  on  the  data  bus  and  taking  some  action  to  attempt  recovery 
from  the  error  condition.  The  ability  of  this  standard  to 
support  degraded  mode  operation  has  resulted  in  widespread  use 
far  critical  military  control  applications. 

The  information  flow  on  the  Bus  consists  of  messages  which  are 
farmed  by  command,  data,  and  status  words.  The  command  word  is 
sent  by  the  bus  controller  and  is  recognized  by  the  remote 
terminal  CRT!)  whose  address  is  indicated  in  the  command  word.  A 
Transmit/Receive  CT/R5  bit  is  provided  indicating  whether  the  RT 
is  to  transmit  or  receive  data.  A  subaddress  within  the  RT  is 
given  along  with  the  number  of  16  bit  data  words  to  be 
communicated.  The  RT  responds  on  a  message  basis  with  a  status 
word  handshake  which  indicates  the  quality  of  the  data 
transmittal  and  the  status  of  the  RT  at  the  time  of  communication 

Broadcast  messages  can  also  be  transmitted  over  the  bus. 
However,  this  message  format  does  not  provide  positive  closed- 
loop  control  of  bus  traffic.  In  the  broadcast  mode,  data  is 
broadcast  by  the  bus  controller  or  by  a  RT  in  reponse  to  a  bus 
controller  command  and  is  received  by  all  RTs  on  the  bus  without 
a  positive  acknaw ledgement .  While  this  message  type  is  not  used 


for  the  transmittal  of  critical  non-reproducible  data,  it  does 
provide  a  means  for  low  overhead  data  transfers  if  applied  care¬ 
fully. 

The  basic  operating  mode  of  the  bus  is  use  of  centralized  control 
of  information  transfers  which,  in  turn,  implies  a  central 
control  system  architecture.  To  provide  added  flexibility,  a 
special  operating  mode  is  provided  that  allows  the  bus  control 
function  to  be  passed  by  the  Bus  Controller  to  an  RT  capable  of 
performing  the  bus  control  function.  This  technique  provides  for 
a  distributed  bus  control  capability  in  a  distributed  processor 
system . 

Although  it  is  technologically  a  relatively  old  standard,  there 
are  several  advantages  to  the  use  of  the  1553B  on  combat  vehicles: 

o  It  is  a  military  standard  with  widespread  use. 

o  An  emerging  fiber  optics  equivalent  provides  a  bandwidth 
with  significant  operating  margin  for  high  speed  BUS  and 
fire  control  data  loops  and  provides  outstanding  noise 
and  EtlP  immunity  with  a  single  interconnecting  fiber/ 
optic  cable. 

o  ULSI  and  UHSIC  devices  are  rapidly  becoming  available 
which  can  perform  the  bus  control  and  remote  terminal 
functions  at  lower  cost. 

o  The  basic  bus  concept  allows  for  subsystem  growth  without 
altering  the  internal  vehicle  wiring,  and  it  supports 
hierarchal  layering  as  well  as  centralized  or  distributed 
processor  control . 

The  primary  disadvantages  of  the  1553  for  this  application  are 
the  high  bus  overhead  and  limited  data  rate,  and  the  cost  of 
interfacing  devices  to  the  bus.  It  may  be  useful  for  the 
transfer  of  significant  command  and  status  signals  around  the 
system,  but  the  combination  of  protocol  overhead  and  the  low  C  M- 
bit/sec)  clock  rate  limit  its  usefulness  within  the  onboard 
control  systems.  Additionally,  the  cost  estimates  range  between 
$2000  and  $3000  for  a  complete  interface,  which  will  severely 
limit  its  widespread  application  m  combat  vehicles. 

IEEE  488  Network 

Developed  primarily  for  short  distance  (under  20  meters)  commun¬ 
ications,  the  IEEE-488  standard  is  a  Byte  Serial,  Bit  Parallel, 
Dultiuser  Asynchronous  Bus.  It  is  oftBn  used  as  an  interface  bus 
between  a  system  and  its  test  support  equipment  for  the  purpose 
of  software  development  and  debug,  system  maintenance,  3nd  fault 
isolation  . 

A  major  drawback  to  the  use  of  IEEE-488  as  a  system  bus  m  this 
application  is  that  it  was  developed  as  an  instrumentation  inter¬ 
face  for  use  in  benign  environments.  As  such,  error  detection  is 


limited  to  parity  checking. 


This  is  a  medium  speed  bus  communicating  at  rates  ranging  From 
250kbps  to  1  megabit/SBC,  but  it  carries  considerable  clock  and 
synch  information  which  adds  substantially  to  thB  communications 
protocol  overhead.  As  an  asynchronous  communication  interface, 
there  is  also  a  risk  that  one  device  may  overload  the  bus  and 
reduce  effective  communication  to  and  From  other  devices.  While 
this  candidate  bus  may  limited  in  a  operational  vehicle  commun¬ 
ications  network,  its  broad  acceptance  by  instrumentation  vendors 
may  be  an  asset  for  depot  level  maintenance  support. 

High  Speed  Data  Bus  CH5DB) 

There  is  considerable  interest  in  defining  a  new  standard  high 
speed  data  bus  for  military  applications.  niL-STD-1553  is 
limited  in  its  ability  to  transfer  at  high  rates  the  large 
amounts  of  data  needed  for  such  systems  as  fire  control, 
navigation,  communications,  electronic  countermeasure,  and  image 
processing.  Currently,  dedicated  interconnections  are  the 
solution  used  to  overcame  data  transfer  limitations.  However, 
this  increases  cabling  weight  and  complexity.  A  high  speed, 
common  bus  method  of  interconnection  would  reduce  both  of  these 
factors,  and  allow  for  straightforward  upgrade  and  expansion. 

Recognizing  the  need  for  a  High  Speed  Data  Bus  CHSDB)  able  to 
communicate  between  avionics  electronics  boxes,  the  Air  Farce  has 
supported  a  Society  of  Automotive  Engineers  Subcommittee  CSAE/AE- 
9B)  which  has  begun  the  development  of  a  MIL-STD-XXXX  HSDB 
Specification.  This  standard  has  also  been  selected  by  FflC 
Corporation  for  its  candidate  Uetronics  data  bus  architecture. 

The  HSDB  is  still  under  development,  but  the  characteristics 
described  in  an  early  PAUE  PILLAR  report  Cref.  12?  are  listed  in 
Table  4-4. 

IEEE  B02  STANDARDS 

Local  area  networks  (LANs?  are  currently  being  examined  as  a 
commercial  solution  to  high  speed  data  transfer  problems  between 
computers  and  other  digital  devices  separated  by  moderate 
distances.  The  IEEE  B02  committee  on  local  area  network 
standards  has  been  trying  to  establish  communication  standards 
which  manufacturers  can  meet  and  communicate  with,  but  which  also 
allow  easy  implementation  in  silicon  using  ULSI  technology.  As 
the  standards  have  been  set,  integrated  circuit  manufacturers 
have  been  quick  to  provide  chip  sets  which  meet  and  surpass  the 
requirements . 

The  advantages  of  establishing  a  military  high  speed  data  bus 
standard  based  on  the  work  already  done  by  the  IEEE  002  committee 
are  the  potential  low  cost  and  wide  availability  due  to  the  broad 
support  of  the  standards  by  commercial  and  industrial  users. 
Unique  military  requirements  can  be  accommidated  by  modifications 
of  exisitng  chip  sets  or  by  using  optional  capabilities  which 


already  exist  in  Cor  can  be  designed  into)  LAN  support  chips  (For 
example,  the  Intel  825B6  LAN  controller  discussed  below) . 

Three  draft  standards  have  been  issued  by  the  IEEE  802  committee, 
and  the  fallowing  paragraphs  summarize  the  key  elements  of  each. 


IEEE  802.3  :  CSMA/CD  using  Baseband  Technology 

CSMA/CD  stands  for  Carrier  Sense,  Multiple  Access  with  Collision 
Detection.  The  "Ethernet”  communications  network  meets  this 
standard.  It  is  a  contention  methodology,  which  means  that  all 
devices  attached  to  the  bus  uhich  have  a  message  to  transmit  must 
compete  For  the  bus  on  a  first  come,  first  serve  basis.  If  two 
or  more  devices  try  to  communicate  on  the  unused  bus  at  the  same 
time,  a  collision  is  detected.  After  each  unit  waits  a  random 
interval  of  time,  retransmission  is  attempted  and  another  check 
for  collisions  is  made.  This  process  is  repeated  until  the  bus 
line  is  free.  Line  access  is  probabilistic  in  this  methodology 
rather  than  deterministic,  which  means  that  it  is  possible  Cbut 
very  unlikely)  for  a  message  to  never  get  accross  the  bus  due  to 
repeated  collisions.  Intel  currently  manufactures  the  82586  LAN 
controller  which  is  based  on  a  CSMA/CD  methodolgy,  but  allows  the 
communication  parameters  to  be  optimized  for  particular  appli¬ 
cations  and  provides  a  method  of  prioritizing  messages. 


IEEE  802.4  :  Taken  Bus 

The  Manufacturing  Automation  Protocol  CMAP)  standard  which  is 
being  accepted  as  a  defacta  standard  by  major  industrial  manu¬ 
facturers  uses  the  IEEE  802.4  standard  as  its  method  of  physical 
transmission.  In  this  methodology,  a  short  message  C token)  is 
passed  between  all  stations  connected  to  the  bus.  This  token 
Freely  travels  until  a  station  ready  to  transmit  a  message 
receives  the  token.  This  station  changes  the  token  to  indicate 
that  the  bus  is  busy,  and  then  puts  the  message  it  wants  to 
transmit  onto  the  bus.  After  the  message  is  transmitted  and 
received  by  the  specified  station,  the  token  is  returned  to  the 
bus  as  a  free  token  and  it  circulates  until  another  station  is 
ready  to  transmit,  and  marks  the  token  as  busy.  Although  the 
token  method  is  slightly  more  complicated,  especially  at  system 
initiation,  the  advantage  is  that  line  access  is  deterministic. 
The  maximum  amount  of  time  it  takes  far  any  station  to  get  access 
to  the  bus  is  fixed,  and  can  be  controlled. 


IEEE  802.5  :  Taken  Ring 

This  standard  is  being  supported  by  IBM  in  its  new  network 
products.  The  fundamental  concept  oF  the  tokBn  remains  the  same 
as  above,  but  the  topology  of  the  interconnect  is  a  ring  rather 
than  a  bus.  TherB  are  several  advantages  to  thB  token  ring 
methodology . 


4-19 


o  As  with  the  token  bus,  line  accese  ia  deterministic,  which 
means  that  a  particular  node  can  always  get  access  to  the 
network  within  a  predefined  maximum  delay. 

o  A  single  twisted  pair  can  serve  as  the  trunk  line  of  the 
ring  Cor  two  twisted  pairs  for  redundancy  as  discussed 
below) . 

o  The  termination  characteristics  of  the  ring  at  any  station 
connection  are  fixed,  regardless  of  the  number  of  nodes  on 
the  total  ring,  since  only  a  single  transmission  line  runs 
between  two  adjacent  stations,  and  the  line  is  terminated 
at  each  end . 

a  A  new  station  may  be  added  to  the  ring  at  a  node  even 
while  the  ring  is  active. 

o  A  failed  node  can  be  electrically  removed  from  the  ring 
even  while  it  is  mechanically  still  attached. 

In  its  generic  processor  study  Cref.  10),  Texas  Instruments 
described  its  Uetronics  concept,  which  adds  a  second,  redundant 
twisted  cable  trunk  line  to  its  implementation  of  the  IEEE  002.5 
taken  ring.  This  second  line  allows  the  ring  to  recover  from  a 
single  break  occur ing  anywhere  in  the  line.  This  network  is  used 
for  command  level  communication  between  processing  nodes  within 
the  Uetronics  architecture. 

Texas  Instruments  has  developed  and  released  a  6  chip  set  for 
interfacing  to  the  ring  and  has  reported  plans  to  reduce  the 
count  to  3  chips.  The  chip  set  is  built  to  military 

specifications,  but  hasn’t  yet  been  validated.  A  commercial 
version  is  currently  marketed  for  use  in  a  commercial  IBM’s 
network  system. 


4. 2. 2. 2  Internal  Bus 

In  addition  to  the  increasing  data  transfer  demands  placed  on 
system  data  buses,  a  similar  problem  exists  within  functional 
modules.  Typically  referred  to  as  an  internal  bus,  these  module 
to  module  communication  buses  are  required  to  transfer  infor¬ 
mation  between  modules  within  a  given  function.  In  the  past, 
these  buses  were  not  an  issue  so  long  as  an  appropriate  Bin  (Bus 
Interface  Module)  was  included  which  would  convert  a  supplier’s 
proprietary  internal  bus  to  a  standard  external  bus  interface. 

With  the  development  of  ULSI  and  UHSIC  single  board  computers, 
however,  the  need  to  standardize  the  internal  bus  must  also 
become  a  priority  issue.  In  recognition  of  this,  a  development 
requirement  for  a  standard  internal  bus  (IBUS)  was  included  as 
part  of  a  recent  U.S.  Air  Force,  UHSIC  1750A  Computer  Development 
Specification  (ref.  12). 
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The  I  BUS  is  intended  to  interconnect  competing  resources  and  I/O 
devices  in  a  relatively  autonomous,  circuit  switched  environment. 
The  IBUS  consists  of  a  network  of  multi-level,  multi-drop  busses 
providing  arbitrary  connections  of  data  processors,  array  or 
signal  processors,  and  peripheral  devices.  IBUS  extension  beyond 
a  functional  module  set  is  intended  to  be  for  very  short 
distances . 

As  shown  in  Table  4-4  the  IBUS  is  applicable  to  computing  systems 
in  which  the  total  bandwidth  required  for  interprocessor  commun¬ 
ication  can  be  obtained  by  interconnecting  processors  via  one  or 
more  shared  busses.  The  multi-drop  approach  minimizes  the  inter¬ 
connections,  and  fully  utilizes  the  available  bandwidth. 

Duplicate  and  Redundant  paths  provide  fault  tolerant  features 
within  the  system.  These  alternate  paths  would  be  used  in 
instances  where  a  bus  or  coupler  along  a  path  was  suspected  of 
failure.  The  master  can  reconfigure  the  transaction  path  by 
changing  the  set  address  definition. 

Any  command  can  address  up  to  255  devices  on  a  bus.  In  addition, 
the  development  specification  allows  for  a  ’’Pass  Through  node”, 
where  commands  may  be  "piped"  to  another  IBUS  within  the  network. 

The  specification  also  describes  a  broadcast  mode  which  allows  a 
master  to  write  the  same  data  to  multiple  slaves.  Broadcast 
transactions,  however,  are  limited  to  a  single  bus  level,  so  data 
can  not  be  written  to  any  devices  or  nodes  requiring  a  bus 
coupler  relay  operation. 

Each  terminal  type  IBUS  interface  device  has  the  ability  to 
accept  and  save  the  basic  set  of  parameters  needed  to  define  the 
origin  or  destination  of  data  during  a  bus  transaction.  The 
development  specification  refers  to  this  basic  information  as  the 
Stored  Address  Parameter  Set  CSAP5) .  This  information  is 
necessary  in  a  read  type  operation  where  the  direction  of  data 
flow  on  the  bus  is  reversed  immediately  following  transmission  of 
a  SAPS  read  type  header.  Read  and  write  transactions  permit  the 
transfer  of  up  to  4096,  16  bit  data  words. 

Through  the  standardized  internal  bus  development,  a  common 
module  concept  (as  described  in  the  Common  Module  Fire  Control 
System  Study,  ARDC  contract  DAAK10-83-R-0031  can  provide 
expanded  capabilities  by  the  simple  addition  of  plug-m,  bus- 
compatible  modules.  Whereby  external  bus  approaches  have  allowed 
Line-Replaceable-Units  to  be  added  to  a  bus,  the  standardized 
internal  bus  approach  will  allow  Lme-Replaceable-Modules . 


4.2.3  PACKAGING  CONSIDERATIONS 

Previous  development  efforts  have  allowed  manufacturers  to 
develop  equipment  within  packages  independently  defined  by  each 
manufacturer.  There  has  been  considerable  effort  made  towards 
establishing  some  standards  for  packaging  for  example,  the 


Military  Computer  Family  CMCF)  form  Fit  standards;  and  the 
Standard  Electronic  Module  (SEM)  effort;  with  the  following 
benef its: 

o  Interconnection  between  products  from  different  manufac¬ 
turers  within  a  common  housing 

o  Support  of  the  philosophy  of  the  "Common  Module” 

a  Reduced  cast  of  common  elements  (such  as  housings)  due  to 
increased  use  across  modules  with  different  functions 

o  Reduced  hsndling  expenses 

o  Reduced  maintenance  cost 

A  widely  used  measure  for  sizing  of  electronics  cards  Cand  the 
assemblies  that  enclose  them)  is  the  Air  Transport  Rack  (ATR). 
Standard  card  sizes  include  1/2,  3/4,  and  Full  ATR. 

Of  particular  interest  to  future  combat  vehicle  developments 
should  be  a  format  based  on  the  3/4  ATR.  This  card  size  can 
support  efficient  packaging  of  functional  modules  required  for 
FCS/BMS,  is  compatible  with  current  analog  electronics  technol- 
ogy,  and  is  being  strongly  supported  in  UHSIC  development 
programs  by  all  three  service  branches. 

A  general  specification  for  a  3/4  ATR  module,  referred  to  as  the 
SEM-E  format,  is  close  to  completion.  Some  of  the  key  physical 
features  are  described  beloui: 


WIDTH  5. as  Inches  C 149.4  cm) 

HEIGHT  6 .68  Inches  C1S9.7  cm) 

STD  THICKNESSES  .290  C7.37) 

.380  (9. SB) 

.480  (12.20) 

.580  (14.74) 

STD  CONNECTORS  100  Pm 

150  Pin 

200  Pin 

250  Pin 

UNIQUE  KEY  120 

CONFIGURATIONS 

MIN  MATING/  500 

UNMATING  CYCLES 

MIN  LIFE  EXPECT.  100,000  Hours 


Specifications  have  also  been  released  for  the  First  set  of 
module  functions.  These  functions  are  also  applicable  to 
military  vehicles  and  the  fire  control  function.  Descriptions 
for  a  subset  of  these  functional  modules  directly  applicable  to 
the  CMFC  effort  are  below: 

Scalar  Processor:  The  Scalar  Processor  will  consist  of  a  HIL- 
STD-1750A  Instruction  Set  Architecture  CPU  with  256K  bytes  of 
dedicated  local  memory.  The  Scalar  Processor  module  shall  be 
capable  of  a  minimum  3  million  instructions  per  second  CHIPS) . 

Array  Processor-.  The  Array  Processor  shall  be  able  to  process 
complex  arithmetic  with  the  capability  of  performing  40  million 
operations  per  second  CHOPS) . 

Bulk  Hemory :  The  Bulk  Hemory  will  consist  of  16H  words  of  non¬ 
volatile  memory.  It  will  be  used  for  program  storage  and  bulk 

data  storage . 

HIL-STD-1553B :  This  module  will  consist  of  two,  redundant  HI L- 
STD-1553B  Hultiplex  Bus  interfaces.  The  bus  shall  be  programable 
to  operate  in  either  Hastar  or  Remote  mode. 

IEEE  408:  This  module  shall  have  two  IEEE  480  Bus  interfaces  to 
be  used  for  connection  to  and  control  of  maintenance  equipment. 

Dedicated  Interface:  This  module  may  actually  represent  a  family 
of  modules.  The  purpose  of  each  module  in  the  family  is  to 
provide  buffering  and  control  circuitry  for  interfacing  discrete 
input  and  output,  such  as  analog,  synchro,  serial,  TTL  level, 
frequency,  etc. 

Power  Supply:  The  Power  Supply  modules  may  actually  be  a  family 
of  modules  each  of  which  conditions  the  vehicle  power  C input)  as 
needed  for  operation  of  the  electronic  modules  Coutput) . 
Standard  modules  must  be  stackable  to  provide  additional  power 
when  the  power  requirements  of  a  chassis  exceed  the  capabilities 
of  a  single  Power  Supply  module. 

Other  nodules:  Additional  requirements  will  require  other 
functions  to  be  provided  on  modules.  For  example,  communications 
between  chassis  will  require  additional  circuit  level  support  as 
standards  emerge  and  the  volume  of  data  to  be  transfered 
increases.  Emerging  standards  such  as  the  High  Speed  Data  Bus, 
and  a  military  version  of  IEEE  802.5  can  each  be  supported  by  a 
module.  As  technologies  advance  and  new  functions  and  capabil¬ 
ities  are  added  to  vehicle  requirements,  new  modules  can  be 
developed  within  these  Electronic  nodule  specifications.  Examples 
of  these  would  be  Uideo  nodule,  Graphic  Processing  nodule,  Signal 
Processing  nodule,  etc. 


4.3  BMS  CONTROL  AND  DISPLAY 


Block  1 1  M1A1  FCS/BMS  has  a  number  of  raqulremants  for  oper¬ 
ational  displays  and  controls  for  the  tank  commander  and  gunner. 
These  include.- 

Gunner’s  Sight  Control  and  Display 

Firs  Control  Computer  Control 

CITU  Display  and  Controls 

BUS  Digital  Messaging  Display 

BflS  Command  and  Data  Entry  Panel 

BMS  Digital  Map  Display  with  Overlaid  Symbology 

Because  space  is  such  a  premium  inside  a  combat  vehicle,  and  to 
simplify  the  soldier/machine  interface,  operator  displays  and 
controls  should  be  shared  between  functions  where  practical .  BMS 
messaging,  BMS  command  and  data  entry,  and  digital  map  display 
with  overlaid  symbology  are  logical  candidates  to  share  a  single 
display  to  the  vehicle  commander. 

This  section  will  discuss  only  the  new  requirements  associated 
with  BMS,  since  FCS  control  and  display  are  well  known  and  are 
not  a  primary  issue  in  this  study. 


4.3.1  DISPLAY  TECHNOLOGY 

Selection  of  a  display  screen  technology  for  this  application 
will  be  driven  by  several  factors,  including-.  Cost;  Performance; 
Compatability  with  other  subsystems  and  sensors;  Readability 
under  all  conditions  C including  direct  sunlight);  EMI; 
Reliability;  Maintenance;  Size;  and  Technology  availability.  The 
driving  technical  requirements  will  be  related  to  BMS  display 
characteristics.  Recent  Ft.  Knox  studies  suggested  the  need  for 
an  8”  (minimum)  diagonal  screen,  with  a  500  x  500  display 
resolution . 

Several  display  technologies  are  available,  including: 

LCD  (Liquid  Crystal  Displays) 

EL  (Thin  Film  Electroluminescent) 

CRT  (Cathode  Ray  Tube) 

AC  Plasma 
Flat  Panel  CRT 

Key  characteristics  for  these  technologies  are  summarized  m 
Table  4-5. 

Liquid  Crustal  Displays  ( LCD ' s ) 

LCD’s  provide  good  resolution  for  this  application.  LCD's  are 
lightweight,  have  a  very  small  form  factor  and  operate  at  low 
power.  LCD  panels  offer  better  viewing  m  direct  sunlight  than 
other  display  technologies.  However  LCD's  require  direct  light  or 
backlighting  (with  flourescent  tubes)  for  visibility.  A 


disadvantage  of  LCD’s  is  performance  degradation  at  lower 
temperatures.  Large  LCD  screens  are  relatively  difficult  to 
manufacture,  and  LCD’s  can  only  be  viewed  from  a  narrow  angle. 
Poor  contrast  may  present  other  viewing  problems.  Color  LCD’s 
are  now  available,  and  are  used  in  commercial  portable 
televisions,  but  only  with  small  screen  sizes. 

Electroluminescent  (EL)  OlsDlaus 

EL  displays  provide  high  brightness,  low  power  consumption,  very 
small  form  factor,  operation  over  the  military  temperature  range, 
shock  resistance,  and  response  time  adequate  for  video.  EL 
screens  are  gaining  wider  use  in  commercial  applications 
(automobile  dashboards  and  portable  computers),  and  increased 
volumes  are  reducing  costs.  EL  screens  have  sufficient  brightness 
to  be  viewable  in  direct  sunlight.  flulticolor  EL  screens 
(currently  only  in  the  development  stage),  utilize  a  stacked 
phosphor  approach  with  no  reduction  of  resolution.  Good  gray 
scale  EL  displays  are  commercially  available  now.  However,  the 
screen  sizes  and  resolutions  required  for  color  BUS  displays  are 
not  yet  commercially  available. 

CRT’s  (Cathode  Rau  Tubes) 

CRT’s  offer  very  mature  technology  with  sufficient  resolution, 
gray  scale  or  color  presentation,  and  frame  rates  suitable  for 
combat  vehicle  application.  Conventional  CRT  displays  are  an 
acceptable  choice  for  a  near  term  BhS  display,  and  a  CRT  is 
currently  utilized  in  the  CITU  display.  CRT’s  typically  require 
mare  maintenance  than  other  technologies  because  of  critical 
alignments  and  fragile  components.  CRT’s  also  require  a  larger 
form  factor  and  more  power  than  any  other  display  technology 
evaluated . 

AC  Plasma  Panels 

AC  Plasma  panels  are  comparable  in  cost  and  performance  to 
standard  CRT's,  but  plasma  displays  do  not  offer  color.  However , 
AC  plasma  panels  are  more  rugged,  require  less  maintenance,  less 
space  &  lower  power,  and  can  be  nuclear  hardened. 

Flat  Panel  CRT's 

Flat  panel  CRT's  provide  many  of  the  advantages  of  traditional 
CRT's,  with  reduced  size  and  more  rugged  construction.  This 
technology  is  relatively  new,  and  will  not  be  available  for  this 
application  for  several  years. 


h.3.2  DISPLAY  ORIENTED  OPERATOR  INPUTS 


The  multi-function  nature  of  the  BfIS  display  function  requires 
program  selectable  control  over  data  inputs.  One  approach  that 
provides  considerable  flexibility  in  this  area  is  that  of  "Touch 
Screen”  sensing. 
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The  use  of  touch  screen  technology  directly  on  the  display 
screens  will  enable  simplified  selection  of  choices  and  data 
entry  for  the  operator.  Noncontinuous  controls  and  operations  not 
typically  performed  under  stress,  and  selections  requiring  many 
discrete  choices  will  utilize  the  touch  screen.  Conventional 
controls  close  at  hand  should  be  utilized  for  critical  and 
continuous  operations  more  likely  to  performed  under  high  stress 
conditions.  The  preferred  design  would  utilize  the  advantages  of 
each  control  technology  in  an  optimal  combination. 

Integrating  a  touch  screen  with  the  operator  display  will  allow 
processing  of  operator  input  for  several  functions:  text, 
graphics,  and  control  selection.  Touch  screens  also  provide  the 
capability  for  greatly  increasing  the  number  of  software 
assignable  operator  selections.  For  application  in  the  M1A1  BfiS 
system,  the  touch  screen  will  be  required  to  be  reliable,  have 
sufficient  resolution  for  use  with  terrain  map  graphics,  not  be 
affected  by  environmental  extremes,  and  not  impede  the  visibility 
of  the  display  screen. 

The  use  of  a  touch  screen  for  interaction  with  the  terrain  map 
display  will  require  a  high  resolution  touch  screen  system. 
Operation  "Gloves-On, “  will  require  a  technique  of  averaging  the 
contact  area  to  define  the  desired  point.  Adjustablity  of  this 
averaging  function  will  create  the  desirable  feature  of  line 
drawing  of  various  line  widths.  Some  of  the  types  of  expected 
touch  screen  interaction  with  BMS  include:  defining  positions  on 
the  map  (friendly,  enemy,  etc.)  with  appropriate  symbol 
designators;  designating  map  positions  for  BUS  system  reporting 
and  calculation  assist  functions  Crange,  angle,  obstacles,  etc); 
simple  drawing  of  tactical  plans;  and  control  selection  of  BMS 
functions  (communications,  automatic  reporting,  function 
selection,  and  data  input). 

As  shown  in  Table  4-6,  there  are  three  primary  technologies 
currently  used  for  touch  screens  (Resitive-Membrane,  Capacitive  & 
LED)  . 

Resistive-Membrane  Touch  Screens 

Resistive  membrane  touch  screens  currently  have  the  highest 
available  resolution  for  touch  screens  (up  to  4000  x  4000 
points).  Resistive  screens  utilize  a  flexible  outer  layer  of 
Mylar  that  is  deformed  when  touched  to  contact  an  inner  layer 
which  defines  the  point  of  contact.  This  Mylar  outer  layer  can  be 
scratched  by  a  stylus  or  dirt.  Resistive  screens  tend  to  limit 
the  optical  transmission  of  the  display  somewhat  because  of 
absorption  by  the  Mylar  and  other  layers  of  the  resistive  screen, 
which  may  also  distort  the  display  color.  Resitive  screens 
require  more  pressure  to  activate  than  other  technologies. 
Resistive  membrane  touch  screens  curve  with  thB  CRT  face  so 
parallax  is  not  a  problem.  Environmentally,  resistive  screens,  if 
not  sealed  well,  can  form  condensation  between  their  layers. 
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Table  4-6.  Touch  Screen  Technologies 


o 


Resistive  -  Membrane 

Capacitive 

LED 

Resolution 
(Typical ) 

Discrete  “16x16 

Analog  “  4,000  x  4,000 

Discrete  ■  16  x  16 
Analog  ■  236  x  256 

25  x  25 

Paral lax 

Error 

no 

no 

yes 

Sty  1  us 

Llml tatlons 

none 

Must  be  conductive 

Must  be  perpendicular 
to  screen 

Durabl 1 Ity 
Considerations 

Coating  wear 
and  scratch  I ng 

none 

Critical  alignment 

Optical 

Clarity 

50J  light  reduction 

Tactical 

Response 

Requ 1  red 

Requires  pressure  to 
deform  Mylar  layer 

Light  touch 

Proximity  &  light  touch 

Environmental 

Considerations 

Humidity 

Sensitive  to  temperature 
&  humidity  changes 

Dust  and 

strong  ambient  light 

Capacitive  Touch  Screens 


Capacitive  screens  can  be  provided  with  either  a  limited  number 
of  discrete  predefined  touch  pads  etched  into  the  display 
surface,  or  by  an  analog  system  that  provides  higher  resolution  - 
up  to  256  x  256  paints.  Capacitive  touch  screens  utilize  a  thin 
cuter  layer  of  resitive  coating  directly  applied  to  a  glass 
surface  over  a  display  device.  Capacitive  screens  are  activated 
by  only  a  very  light  touch,  due  to  capacitive  coupling  between  a 
finger  or  conductive  stylus  and  the  screen  coating.  Capacitive 
screens  may  bB  affectBd  by  temperature  and  humidity  changes 
/unless  electronic  compensations  are  employed!)  . 

LEC  /Light  Emitting  Diode)  Touch  Screens 

LED  touch  screens  have  law  resolution  C limited  by  the  number  of 
individual  LED’s  that  can  be  arranged  around  the  display  screen;). 
LED  touch  screens  do  not  appear  to  currently  have  adequate 
resolution  for  the  BM5  application.  LED  screens  do  not  require 
any  pressure  or  contact,  but  merely  to  break  the  light  beam 
between  the  LED  transmitter  and  receiver.  However,  LED  touch 
screens  can  introduce  a  parallax  error  where  the  light  beams  are 
located  far  above  a  curving  CRT  face  /this  becomes  very  evident 
at  the  edges  of  the  screen).  Environmentally,  LED  screens  can  be 
affected  by  dust  and  strong  ambient'  light. 

4.4  LOCATION,  ORIENTATION,  AND  UEHICLE  DYNAMICS 

Both  the  fire  control  and  battle  management  functions  require 
sensing  of  vehicle  position,  orientation,  and/or  inertial 
dynamics.  Table  4-7  summarizes  the  types  of  data  and  their  uses 
for  Ml A 1  FCS  and  BMS . 

The  basic  technologies  available  for  establishing  this  data  are 
ground-based  radio,  satellite  based  radiD,  and  inertial.  The 
characteristics  of  these  are  summarized  m  Table  4-9. 

Of  particular  interest  to  an  integrated  FCS-'BMS  vehicle  archi¬ 
tecture  is  the  use  of  inertial  technology,  since  a  single  set  cf 
gyros  and  accelerometers  in  the  inertial  measurement  unit  can  be 
used  for  multiple  purposes  within  both  the  FCS  and  BMS.  In  fact, 
a  single  turret-mounted  inertial  reference  unit  could  feed  data 
tc  several  software  modules  tc  provide  all  of  the  data  t3pss 
shown  m  Table  4-7  except  hull  yaw  rate  and  vehicle  driving  speed 
/which  is  assumed  to  be  measured  directly  from  the  power  tram  . 

Prior  to  BMS,  automated  vehicle  navigation  ■■  position  location  was 
desirable  but  net  required  for  close  combat  vehicles.  Since  this 
capability.  when  considered  on  a  standalone  basis,  can  add 
several  thousand  dollars  to  the  cost  of  a  vehicle,  it  has  nct 
been  implemented  on  a  wide  scale.  While  a  relatively  high  cost 
factor  still  exists,  the  differential  cost  to  the  vehicle  ca-  be 
partially  offset  by  using  other  systems  processors  for 
computation  and  by  the  elimination  cf  other  vehicle  equipmsr',t  if 
a  sersor  sharing  architecture  is  adopted. 
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Table  4-7.  Position, Orientation,  and  Dynamics  Data  Requirements 


oata  type 

USED  BY: 

APPLICATIONS/REMARKS 

Vahid.  Position: 

Orld  Position 

BMS 

Provides  location  data;  used  for  map  referencing; 

reference  data  for  navigation  end  force  positioning, 
monitoring  other  vehicle  locations,  and  establishing 
target  locations. 

Altltud. 

BMS 

Cross  reference  to  map  and  features  data 

Vahid.  Orl.nt.tlon: 

FCS 

Part  of  the  ballistic  fire  control  solution 

Hooding 

BMS 

Required  for  navigation;  combined  with  target  range  and  vehicle 
position  to  calculate  absolute  target  position. 

FCS 

Can  be  used  for  ballistic  compensation  If  data  Is  available; 

accuracy  effects  do  not  Justify  adding  a  sensor  for  this  purpose  alone. 

Rol  1 

BMS 

Used  for  coordinate  transformation  of  relative  target  and/or 
feature  positions  to  absolute  coordinates. 

FCS 

Turret  roll  (cant  angle)  Is  required  for  ballistic  solution. 

Pitch 

BMS 

Combined  with  LOS  relative  elevation  angle  to  predict  target  and/or 
feature  location. 

Vahid.  Oynoalcs: 

FCS 

Combined  with  LOS  relative  elevation  to  predict  target  altitude  for 

ballistic  solution;  a  small  effect  for  surface  and  low  altitude  targets. 

Hooding  (Yaw)  Rat.  (•) 

FCS 

Hull  yaw  rate  Is  required  for  turret  stabilization  under  mobile 
operation. 

Roll  Rat.  (•) 

FCS 

Turret  roll  rate  can  be  used  to  Improve  turret  stabilization  under 
under  some  mobile  operating  conditions;  not  cost  effective  If  only 
used  for  this  purpose. 

Pitch  Rat.  (•) 

FCS 

Turret  pitch  rate  Is  required  for  gun  stabilization  under  mobile 
operation. 

Vortical  Accloratloo  (•) 

FCS 

May  be  required  to  stabilize  enhanced  armament;  can  be  used  to 
assist  gunner  tracking  under  mobile  conditions. 

Latoral  Acceleration  (*) 

FCS 

May  be  useful  In  stabilizing  (highly  unbalanced)  turrets  with 

Improved  frontal  armor. 

Longitudinal  Acceleration  (*) 

Vehicle  Driving  Speed  (•)  FCS  Can  be  used  In  ballistic  solution  to  adjust  muzzle  velocity;  can 

be  used  to  assist  gunner  tracking  under  mobile  operation. 

(•)  All  of  these  parameters  ere  used  Indirectly  by 
BNS  If  Inertial  navigation  Is  Implemented  for 
position  location. 
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Table  4-B .  Applicable  Technologies 
and  Dynamics 


Position,  Drientati 


TECHNOLOGY  CHARACTERISTICS  EXAff*LES 

Radio  Line  of  Sight  PLRS/JTIDS 

(Ground  Based)  Accurate  Relative  Position  (15  M) 

Cooperative,  Multi-User 
Jam  Resistant  -  Spread  Spectrum 
Digital  Communication  Integrated  with 
Message  Structure 
No  Vehicle  Attitude  Data 


Radio  Jam  Resistant  GPS 

(Satellite  Based)  Accurate  Position  and  Velocity 
Non  Cooperative,  Receive  Only 
A 1 1  Land  Area  Coverage 
No  Vehicle  Attitude  Data 
Common  Geographic  Coordinate  System 

Inertial  Jam  Proof  -  Non  Radiating  IRNS 

Self  Contained  Measurement  Of:  MAPS 

Position 
Velocity 
True  Heading 
Attitude 
Attitude  Rates 
Vehicle  Accelerations 
Time  Dependent  Accuracy 


PLRS/JTIDS  -  Position  Locating  and  Reporting  System  / 

Joint  Tactical  Information  Distribution  System 
GPS  -  Global  Positioning  Satellite  System 

IRNS  -  Inertial  Reference  Navigation  System 

MAPS  -  Modular  Azimuth  Positioning  System 
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The  key  to  achieving  this  capability  is  a  repartitioning  of  the 
traditional  inertial  navigation  system  data  flow  and  processing. 
To  achieve  reasonable  levels  of  navigation  accuracy,  systems  such 
as  those  listed  in  table  4-9,  typically  sample  and  (where  appli¬ 
cable!)  torque  the  inertial  instruments  at  rates  of  500  to  1000 
Hertz.  This  data  rate  would  also  provide  sufficient  bandwidth  for 
the  stabilization  functions  referenced  in  table  4-7.  Although 
this  data  rate  is  not  normally  available  to  the  external  world 
from  current  navigation  systems,  there  is  no  technical  reason 
that  it  could  not  be  provided. 

Two  basic  approaches  can  be  considered  with  respect  to  this 
repartitioning.  One  is  to  have  a  current  navigation  system  ( I Ru / 
computer)  modified  to  provide  the  required  data  and  rates  at  an 
output  port.  The  other  approach  would  be  to  separate  the  1RU 
functions  (sensing  and  instrument  torquing)  From  the  navigation 
computations.  This  would  result  in  a  lower  cost  inertial  hardware 
package,  the  navigation  software  could  be  implemented  in  another 
multi-function  computer,  along  with  other  processing  that  uses 
the  same  data . 

The  final  cost  of  implementing  inertial  technology  on  close 
combat  vehicles  will  be  proportional  to  the  required  navigation 
accuracy.  The  accuracy  required  for  fire  support  is  represented 
by  the  the  nodular  Azimuth  Positioning  System  (MAPS)  performance 
described  in  table  4-9.  Without  considering  the  cost  offsets 
referred  to  above,  such  navigation  systems  might  C03t  in  the 
range  of  $20,000  to  $30,000.  However,  BHS  for  the  niAl  can 
probably  operate  with  much  looser  specifications,  more  along  the 
lines  of  the  UNAS  system.  This  could  reduce  the  cost 
substantially . 

From  a  fire  control  perpective,  niAl  tanks  which  implement  this 
technology  will  be  able  to  eliminate  the  current  cant  sensor  and 
turret  pitch  rate  gyro,  and  they  will  not  have  to  add  separate 
acceleration  sensors  to  stabilize  the  expected  highly  unbalanced 
enhanced  turrets  and  weapons.  Additionally,  they  can  have 
improved  performance  on  the  move  due  to  the  inherent  availability 
of  additional  dynamics  data  (cant,  pitch,  roll  rate,  etc.)  that 
is  basically  available  for  "no  cost’’  performance  improvements  m 
the  fire  control  software. 


If  cost  becomes  an  overiding  limitation,  a  combination  of 
inertial  and  radio  technology  can  be  used  within  small  units  to 
provide  the  position  data  required  to  support  the  EHS  functions. 


Lear  Siegler  VNAS  Vehicle  Reference  Unit  28 4.5  Cu  Inches  10  2-0S 

He*  Display  Unit  74.3  Cu  Inches  2.3 

Vehicle  Heading  Indicator  20.3  Cu  Inches  0.7 

01  stance  Maas.  Unit  63.4  Cu  Inches  1.8 


5. 


ARCHITECTURAL  CONSIDERATIONS 


The  currant  and  projected  functional  requirements  for  BflS/FCS  Cas 
described  in  section  3D  introduce  the  need  for  substantially  more 
computation,  data  flow,  and  display  capability  than  is  currently 
available  in  the  fll  series  tanks.  The  individual  technologies 
described  in  the  proceeding  section  have  the  maturity  and 
performance  capabilities  required  to  meet  those  functional 
requirements.  Houiaver,  a  major  challenge  for  advanced  FCS/BhS  is 
how  to  integrate  them  into  future  hl-based  turret  systems. 

Up  to  a  certain  level  of  electronic  sophistication,  the  problems 
of  combat  vehicle  integration  are  relatively  straightforward  and 
forgiving.  To  this  point,  combat  vehicles  have  had  to  accomodate 
relatively  feu  electronics  boxes  which  were  performing 
straightforward ,  mostly  linear  control  functions  using  mostly 
analog  electronics.  UJith  the  rapidly  expanding  scope  and 
sophistication  of  BUS  and  FCS ,  however,  the  vehicle  integrator 
must  now  face  many  of  the  same  cost/ueight/volume/complexity 
issues  that  have  challenged  the  aircraft  industry  for  the  past 
two  decades . 

This  discussion  will  reflect  some  of  the  applicable  integration 
experience  of  that  industry  in  establishing  guidelines  For  an 
architecture  for  the  battle  tank  that  exploits  available  elec¬ 
tronic  technology  and  provides  for  growth  within  the  practical 
constraints  of  hi  budgets  and  schedules. 

5.1  GENERAL 

There  is  no  doubt  that  the  architectures  of  combat  vehicles  such 
as  the  hi  tanks  will  be  dominated  by  digital  technology  in  the 
near  future.  However,  there  are  a  number  of  practical  issues  that 
will  limit  the  practical  rate  of  transition.  This  section  wil: 
discuss  some  of  the  key  hardware  architectural  concerns  related 
to  turret-based  electronics  for  combat  vehicles. 

The  general  capabilities  and  tradeoffs  of  analog  and  digital 
processing  are  summarized  in  the  Following  subsection.  Additional 
key  issues  relate  to  the  distribution  of  digital  processing 
Functions  given  the  current  limitations  for  interface  and  inter¬ 
connect,  the  standardization  of  designs  for  growth  compatibility, 
and  the  effects  these  changes  will  have  on  traditional  supplier 
roles  and  system  partitions. 


5.1.1 


ANALOG  US  DIGITAL  PROCESSING 


Nearly  all  of  the  FCS-related  processing  in  Fielded  vehicles  is 
currently  implemented  m  the  form  of  analog  electronics.  The 
single  notable  exception  to  this  is  the  ballistic  computer  in  the 
hi  tank. 

The  primary  reasons  for  the  dominance  of  analog  electronics  have 
been  lower  cost  and  the  throughput  limitations  of  low  cost 
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digital  processors,  which  have  only  recently  reached  acceptable 
performance  levels  for  combat  vehicle  control  problems.  The  cost 
advantage  of  analog  electronics  lies  primarily  in  the  ease  of 
integration  with  the  electro-machemcal  devices  commonly  used  For 
combat  vehicle  fire  control . 


Analog  computation,  by  virtue  of  its  parallel  and  continuous 
processing  characteristics,  is  useful  for  high  bandwidth  control 
problems  with  analog  interfaces,  relatively  well  behaved  load 
dynamics,  and  limited  dynamic  ranges.  Thus,  it  is  still  the  most 
cost-effective  approach  for  such  functions  as  line  of  sight 
stabilization . 


The  primary  disadvantages  of  analog  computation  are  reliability, 
the  lack  of  flexibility,  and  the  high  weight  and  volume  per  unit 
measure  of  computational  performance. 


Digital  processing  is  clearly  the  way  of  the  future  For  combat 
vehicles,  and  an  all  digital  turret  Ci.e.,  uetronics-based )  may 
be  achievable  within  the  next  10  years.  Historically,  compu¬ 
tational  throughput  and  cost  have  been  the  limiting  factors  in 
applications  of  this  nature,  although  system  interface  is  now 
becoming  very  significant. 


All  of  the  processing  requirements  For  the  current  ni  functions 
and  performance  levels  can  be  achieved  with  relatively  low  cost 
processors  using  military  standard  instruction  set  architectures 
and  LSI  or  ULSI  circuit  technology.  The  emerging  requirements  for 
signal  processing  can  be  met  with  newly  developed  UHSIC  circuits 
which  are  planned  to  achieve  practical  production  rates  within 
the  next  two  to  three  years. 


The  major  limiting  factor  to  digitizing  more  turret  functions  is 
the  problem  of  interfacing  to  the  (primarily  analog)  outside 
world  and  the  distribution  of  large  amounts  of  data  between 
points-of-need .  The  TACOM-sponsored  uetromcs  program  is 
attempting  to  define  standards  and  develop  the  necessary  high 
speed  data  buses  and  low  cost  interfaces.  However,  the  practical 
implementation  of  these  technologies  is  still  many  years  away  and 
not  compatible  with  early  application  in  the  HlAi  Block  II 
schedules . 


The  requirements  for  the  remainder  of  this  decade  must,  there¬ 
fore,  be  met  by  "hybrid"  turret  electronics  architectures  which 
retain  analog  control  for  some  functions,  but  m  which  the 
performance  and  function  growth  is  implemented  in  digital  form. 


5.1.2 


DISTRIBUTION  OF  PROCESSING  ELEMENTS 


The  physical  distribution  of  processing  elements  within  a  system 
will  have  a  major  impact  on  its  cost  and  performance.  Analog 
electronics  are  typically  designed  for  a  unique  function  and 
dedicated  to  a  specific,  limited  hardware  interface.  The  various 
circuits  necessary  to  perform  the  required  function  are  typically 
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grouped  into  a  single  box  in  order  to  minimize  cabling  and  the 
problems  associated  with  it. 

Digital  processors  are,  however ,  mors  general  purpose  in  nature, 
and  a  single  hardware  element  may  be  capable  of  performing  • 
number  of  substantially  different  functions.  The  only  limitations 
are  the  basic  computational  power  of  the  processor  and  the 
ability  to  provide  the  input  and  output  data  channels  required 
for  performing  the  functions. 

At  the  extremes,  there  are  two  basic  approaches  to  the  distri¬ 
bution  of  digital  processing  -  distributed  and  centralized. 

Distributed  Processing  follows  a  philosophy  of  physically 
locating  the  processors  at  the  "point-of-need” ,  as  has  been 
traditionally  done  with  analog  combat  vehicle  electronics.  The 
advantages  to  this  approach  include: 

o  High  function  processing  i ates  can  be  achieved  because 
the  processor  is  dedicated  to  that  task. 

This  characteristic  has  been  significant  in  many  prior 
applications  due  to  the  throughput  limitations  of  the 
then-available  digital  technology. 

o  Software  efficiency  and  configuration  control  are 
better  because  the  processor  is  not  being  time  shared 
or  required  to  do  a  wide  variety  of  tasks. 

The  primary  disadvantages  of  distributed  processing  are; 

a  Processors  tend  to  be  application  specific,  which  makes 
it  difficult  to  share  burdens  in  the  event  of  a 
processor  failure  Ci.e.,  graceful  degradation). 

o  The  number  of  processors  increase,  which  creates 
additional  cost  and  increases  the  system  volume  and 
power  requirements. 

o  With  the  trend  toward  standardization,  processors  will 
exist  at  a  few  discrete  throughput  levels.  Unless  a 
function  happens  to  match  exactly,  a  portion  of  the 
inherent  computational  power  of  the  processor  may  be 
wasted . 

One  Uetronics  contractor  is  investigating  the  use  of  a  large 
number  of  standardized  processors  to  control  both  the  data  inter¬ 
faces  and  to  conduct  processing  of  the  required  control  functions 
in  a  truly  distributed  fashion.  This  removes  any  concerns  about 
the  ability  for  graceful  degradation.  However,  the  techniques  for 
distributing  intelligence  in  this  fashion  are  still  quite 
theoretical  and  will  require  considerable  time  to  perfect. 

At  the  other  end  of  the  spectrum  is  centralized  processing,  which 
follows  the  philosophy  of  locating  all  of  the  processors  in  a 


common  box.  Communication  with  tha  points-of-naad  is  via  a  system 
data  bus  and/or  direct  point-to-point  interconnect. 

The  advantages  of  this  approach  are: 


o  Tha  number  of  processors  required  by  the  system  is 
minimized  by  time-sharing  across  functions. 

o  Remaining  proceesora  can  share  the  burden  in  the  event 
of  a  proceaaor  failure. 

o  It  is  well-suited  to  processing  growth,  particularly 
that  associated  with  extracting  more  performance  or 
function  from  existing  system  data. 

o  For  a  given  level  of  system  processing,  this  generally 
will  have  the  lowest  processor  production  costs. 

The  disadvantages  of  centralized  processing  are-. 

o  It  requires  higher  data  rates  for  the  system  inter¬ 
connect.  This  may  excaed  the  capacity  of  current  data 
bus  technology. 

o  It  may  lead  to  mors  cabling  in  systems  that  require 
point-to-point  interconnect  in  addition  to  data  buses. 

In  practice,  neither  of  these  approaches  is  entirely  satisfactory 
for  combat  vehicle  Bns/FCS  applications.  The  most  appropriate 
architecture  is  a  combination  of  these,  in  which  a  limited  number 
of  "packets  of  centralized  processing”  are  distributed  in  the 
system . 

This  "Federated”  approach  is  flexible,  compatible  with  the 
processing  requirements  of  a  combat  vehicle,  and  well-suited  for 

growth.  In  this  approach,  functions  with  high  data  flow  rates  and 

those  which  might  share  sensor  data  are  grouped  into  a  single 
processor  assembly  Ci.e.,  centralized).  Some  point-of -need 

processing  is  distributed  throughout  the  system,  but  it  is 

basically  limited  to  that  required  to  filter  and  format  data  for 
the  system  bus. 

In  the  extreme  applications  of  this  architecture,  a  simple  combat 
vehicle  (e.g.,  an  IFU)  would  have  a  single  processor  assembly  for 
all  8MS/FCS  Functions,  while  an  advanced  tactical  aircraft  might 
have  10  or  more  assemblies  operating  on  various  sensors  and 
mission  functions. 

5.1.3  STANDARDIZATION 

The  concept  of  embedded  computers  is  being  considered  for  many 
military  applications.  The  reason  is  that  many  functions  which 
once  required  "black  boxes"  can  now  be  performed  by  a  single  Cor 
two)  board  module.  A  second  but  equally  important  reason  is  that 
it  provides  an  approach  to  a  system  configuration  which  allows 
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flexibility,  growth  and  low  coat  system  tailoring  by  insertion  or 
removal  of  plug-m  modules.  Practical  application  of  this 
approach,  however,  requires  standardization  of  the  internal  con¬ 
figuration  of  electronic  boxes. 

Historically  the  internal  communication  within  an  electronics  box 
(Line  Replaceable  Unit)  was  not  a  system  design  issue  and  only 
the  external  interfaces  needed  to  be  standardized.  UHSIC  and  ULSI 
technology  development,  however,  has  made  it  possible  to  place 
entire  functions  (even  multiple  functions)  on  a  single  board 
which  can  be  packaged  as  a  plug-m  module. 

To  accomodate  this  new  generation  of  electronics,  the  concept  of 
the  expandable  chassis  with  a  backplane  consisting  of  a  high 
speed  data  bus  and  a  standard  internal  control  bus  (I BUS)  has 
evolved.  This  approach  requires  bath  the  electronics  interface 
and  the  physical  interface  to  be  defined  so  that  cards  may  be 
added  or  removed  from  the  chassis  to  achieve  the  performance 
characteristics  desired.  With  this,  future  growth  can  be 
accomodated  by  the  simple  insertion  of  additional  interface- 
compatible  cards. 

P  key  element  of  the  expandable  chassis  concept  is  the  Standard 
Electronics  nodule  (SEn.)  Combining  this  standard  for  the 
physical  parameters  of  electronics  with  the  electronics  bus 
standards  described  earlier  will  allow  competitive  development 
and  procurement  of  plug-compatible  modules. 

There  is  extensive  military  support  for  the  development  of  a 
physical  configuration  far  these  plug  compatible  modules.  The 
SEn-E  configuration  appears  to  be  a  prime  candidate  configuration 
for  these  modules.  This  physical  configuration  will  fit  into  a 
3/4  ATR  form  factor  and  allows  for  varying  module  thicknesses. 

Consider  an  example  of  how  the  expandable  chassis  concept  can  be 
applied  to  accomodate  future  growth  in  the  rilAl .  Current 
computing  requirements  for  the  H1A1  Block  II  change  can  be 
accomplished  with  a  single  board  ULSI  processor  module.  As  til 
FCS  and  BhlS  enhancements  are  incorporated  during  the  next  decade, 
image  processing  and  other  processor  intensive  demands  will  be 
established.  To  meet  the  higher  processor  requirements,  the 
standardized  expansion  chassis  concept  offers  two  options 

'1)  A  UHSIC  processor  may  be  plugged  into  the  chassis 
directly  replacing  the  ULSI  processor,  or 

(2)  Additional  ULSI  processor  modules  may  be  added. 

The  latter  approach  is  currently  being  applied  on  the  EF111 
aircraft  to  obtain  data  processing  rates  in  excess  of  5  MIPS. 

In  summary,  the  advantages  of  hi  conversion  to  the  standard 
module  concept  are  exceptional  flexibility,  expandability  and 
cost  savings  offering  a  logical  growth  opportunity  to  support 
advanced  BH5  and  Fire  Control  processing  needs  as  they  develop. 


These  advantages  must  be  weighed,  however,  in  terms  of  the 
current  Ml,  Block  II  requirements.  To  do  so,  the  issues  of 
schedule  and  costs  for  converting  this  approach  must  be 
considered.  Conversion  to  a  standard  module  format  creates  some 
risk  in  meeting  ni  Block  II  schedule  requirements.  A  planning 
strategy  can  be  established,  however,  which  would  reduce  this 
risk.  It  would  require  physical  and  communication  interfaces  to 
be  selected  so  that  they  will  allow  a  plug  compatible  upgrade  to 
UHSIC  or  OLSI  as  new  requirements  Ce.g.,  digital  imaging)  are 
placed  on  the  m .  The  risk  involved  from  a  schedule  standpoint 
can  be  reduced  by  designing  in  certain  features  which  are 
supported  by  all  technology  approaches  and  taking  advantage  of 
developments  already  underway.  This  would  include  a  physical 
form  factor  and  a  standard  bus  interface  (i.e.,  the  expandable 
chassis  form  factor  with  a  standard  physical  interconnect) . 


5.1.4  SUBCONTRACTOR  ROLES  ANO  SYSTEM  PARTITIONING 

At  this  point  it  is  important  to  consider  an  additional  factor  m 
current  design  and  procurement  policiee  that  stands  face  to  face 
with  the  pure  technical  tradeoffs  normally  considered  in  studies 
such  as  this.  That  is  the  traditional  contractor  roles  in  tank 
system  development. 

In  the  '•pre-electronics"  days  of  tank  fire  control,  the  functions 
being  performed  were  simple  and  implemented  by  straightforward 
optical  and  mechanical  designs.  The  technologies  involved  were 
basically  those  of  power  drives  for  the  gun  and  turret,  optics 
for  target  viewing,  and  semi-precision  mechanical  links  to 
connect  the  gun  and  sight.  The  equipment  was  procured  from 
companies  specializing  in  those  technologies. 

As  performance  requirements  grew  and  electronic  controls  and 
linkages  developed,  the  suppliers  of  these  systems  added  elec¬ 
tronics  to  their  designs  and  provided  "integrated”  subsystems. 
And,  as  new  functions  were  added,  new  electronics  boxes  were 
designed  and  procured.  This  was  a  reasonable  technical  approach 
because  of  the  limitations  and  dedicated  nature  of  analog  elec¬ 
tronics.  From  the  subcontractor  business  perspective,  it  was 
desirable  because  of  the  value  added  to  the  product. 

As  a  result  of  this  heritage,  it  has  been  traditional  in  combat 
vehicles  to  procure  the  "intelligence"  required  for  any  pomt-of- 
need  as  a  package  with  that  item.  Thus,  power  drives  are 
"integrated"  with  gun  and  turret  stabilization  electronics, 
ballistic  computation  is  in  a  separate  box  that  is  "integrated” 
with  another  control  and  display  electronics  box,  and  line  of 
sight  drives  are  "integrated”  with  sight  stabilization  elec¬ 
tronics  -  to  name  a  few. 

The  transition  to  digital  technology  that  has  been  occurmg  in 
fire  control,  and  will  be  accelerated  by  the  BMS  requirements, 
does  not  require  this  distribution  of  intelligence.  And,  in  fact, 


the  Increasing  need  to  access  and  share  data  across  these  sub¬ 
systems  makes  it  generally  undesirable. 

The  development  of  an  architecture  for  advanced  FCS/BMS  support 
in  the  M1A1  should  include  a  re-examination  of  the  traditional 
procurement  partitioning  in  light  of  today’s  technology  and 
system  requirements.  The  familiarity  of  subcontractors  with  their 
traditional  products  and  their  desire  to  retain  as  much  value- 
added  on  their  side  of  the  interface  will  usually  make  the  near 
term  costs  favor  retention  of  traditional  responsibilities. 
However,  the  long  term  benefits  of  today’s  technology  and 
anticipated  growth  may  point  to  other  approaches. 

The  problems  associated  with  growth  by  "box  proliferation”  are 
well  known  in  the  defense  industry,  and  include  the  following 
which  are  particularly  significant  to  the  M1A1: 

Increased  equipment  weight  and  volume  requirements 

Communications  and  Cabling  between  subsystems 

Maintenance  and  Training 

Spares 

Unnecessary  redundancy  of  sensors 

Difficult  System  integration 

Bulky  interconnections 

Not  suitable  for  graceful  degradation 

Poor  framework  for  growth 

Higher  cost  due  to  non-standardized  components 


The  n 1  has  already  reached  an  integration  saturation  point,  and 
with  the  addition  of  BMS,  it  may  be  appropriate  to  undertake  a 
more  extensive  near  tarm  design  modification  in  order  to  avoid 
much  larger  problems  in  the  future. 


5.2 


M1A1  FIRE  CONTROL  AND  INTERFACES 


It  was  established  in  proceeding  sections  that  there  is  a  strong 
and  complementary  relationship  between  fire  control  and  vehicle- 
mounted  BMS,  and  that  the  interfaces  will  become  even  more 
significant  with  the  anticipated  growth  in  both  subsystems. 
Because  of  the  large  number  of  already  fielded  systems,  any 
practical  solution  for  implementing  BMS  and/or  growth  in  fire 
control  must  evolve  from  the  current  FCS  architecture. 
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This  section  describes  the  key  characteristics  of  the  rtlAi  FCS 
C including  CITU)  that  must  be  considered  in  selecting  an  archi¬ 
tectural  approach  for  BfIS/FCS  and  growth.  Sines  there  is  no  BhS 
currently  on  the  niAl,  it  is  not  addressed  here,  although  a 
summary  of  the  preliminary  requirements  may  be  Found  m  Section 
5.3. 

To  maintain  clarity,  the  fire  control  (pointing,  moding,  and 
control)  functions  are  discussed  separately  from  the  operator 
interface  characteristics  (information  display  and  control). 
Areas  that  will  probably  require  change  due  to  new  requirements 
or  for  growth  compatibility  are  also  identified. 

5.5.1  POINTING,  flODING,  AND  CONTROL 

Figures  5-1  and  5-5  illustrate  the  current  fire  control  archi¬ 
tecture  for  the  H1A1  in  azimuth  and  elevation,  respectively. 

The  primary  reference  device  For  the  M1A1  FCS  is  the  gunner's 
primary  sight  (GPS),  whose  lines  of  sight  are  directed  by  a 
sighthead  mirror  and  reticle  drive  assembly.  The  mirror  is 
independently  stabilized  in  elevation  and  mechanically  linked  to 
the  turret  in  azimuth. 

A  digital  computer  calculates  the  weapon  offset  angles  required 
to  compensate  far  parallax,  ballistics,  and  (in  azimuth)  target 
motion  using  range,  cant,  and  crosswind  data  from  automatic 
sensors  together  with  manual  inputs  for  other  significant 
parameters.  The  computed  angles  are  updated  approximately  30 
times  per  second  and  transmitted  to  external  electronics  for 
servo  processing. 

The  digital  computer  (CEU)  is  based  on  the  TI  9989  processor 
chip,  is  approximately  h "  x  9"  x  13”  in  size,  and  weighs  slightly 
over  56  lbs.  It  contains  7  electronics  boards  -  a  CPU  board,  a 
ROM  board,  H  PQ  boards,  and  1  for  9900-senes  chip  maintenance 
functions.  It  was  designed  as  a  low  cost  solution  to  the  M1 
ballistic  computation  problem. 

The  gun  and  turret  are  controlled  by  electro-hydraulic  servos.  Ir' 
elevation,  the  gun  is  controlled  by  a  position  servo.  Resolvers 
measuring  the  LQ5  and  gun  elevation  angles  are  electrically 
chained  and  routed  to  the  turret  networks  box  CTNB).  An  elec¬ 
tronic  circuit  (DCT)  in  the  turret  networks  box  compares  those 
relative  angles  to  the  commanded  offset  from  the  computer,  and 
the  difference  is  sent  to  the  gun  servo  as  an  error  signal .  The 
gun  servo  then  drives  the  gun  to  zero  out  this  error,  resulting 
in  a  continuous  repositioning  of  the  gun  to  the  current  commanded 
firing  angle.  Gyros  and  base  motion  sensors  are  included  in  the 
gun  servo  to  improve  the  dynamic  positioning  accuracy  while  the 
vehicle  is  moving. 

The  turret  is  controlled  in  azimuth  by  a  rate  servo,  and  since 
the  sighthead  mirror  is  fixed,  the  turret  servo  also  controls  the 
nominal  LQS  in  azimuth.  Lead  angles  are  implemented  by  moving  the 


Figure  5-5.  MlAl  Fire  Control  System  (Elevation) 


reticle  within  the  eight  field  of  view  and  counter  rotating  the 
turret  (and  sight  field  of  view)  to  maintain  the  reticle  on  the 
target.  Reticle  dynamic  accuracy  under  mobile  operation  is  also 
improved  by  compensating  for  the  measured  turret  stabilization 
error.  ThB  reticle  drive  computations  are  accomplished  in  the 
ballistic  computer. 

With  the  exception  of  the  control  panel  inputs,  laser  range,  and 
the  offset  commands,  the  FCS  architecture  is  essentially  a  point- 
to-point  analog  interconnect.  The  gun,  turret,  and  sight  servos 
are  mechanized  as  analog  electronics.  The  operators’  control 
handles  are  hardwired  to  the  gun  and  sight  control  electronics. 
The  cant  and  crosswind  sensors  are  routed  to  the  computer  and 
converted  to  digital  format  for  processing. 

The  above  architecture  is  expanded  with  the  addition  of  the 
Commander's  Independent  Thermal  Yiewer  (CITY) .  The  CITY  is  an 
independent  sight  which  is  controlled  by  its  own  two-axis  Canalog 
electronics)  stabilization  system.  The  system  moding  allows  the 
CITY  to  operate  independently,  to  be  used  as  a  gunsight,  or  to 
designate  targets  to  gunner.  When  it  is  operating  within  the  FCS 
structure,  DCT-based  position  loops  (similar  to  that  For  the  BPS 
and  gun  in  elevation)  are  established.  To  avoid  ambiguity  in 
elevation,  a  second  frequency  is  added  into  the  resolver  chain. 

As  described,  the  FCS  meets  the  documented  performance  require¬ 
ments  for  the  M1A1 .  However,  there  is  little  or  no  capacity  for 
growth  within  the  current  architecture.  The  current  ballistic 
computer  cannot  accept  much  additional  sensor  processing  or 
substantially  improved  control  algorithms  due  to  throughput 
limitations  of  the  processor  technology  being  used.  The  analog 
compensation  circuits  far  the  gun  and  turret  drives  may  not  be 
adequate  for  anticipated  growth  in  gun  and  turret  unbalances. 
Finally,  in  an  advanced  turret  (with  BM5  and  other  growth  items) 
it  may  occupy  too  much  space  for  the  function  provided. 

The  CITY  has  been  specified  to  have  a  growth  capability  far 
interface  to  a  MIL-STD-1553B  data  bus,  although  the  specified 
data  interface  appears  to  be  limited  to  image  control  and  display 
functions . 

5.2.2  INFORMATION  DISPLAY  AND  CONTROL 

The  basic  FCS  control  and  display  interface  to  the  operators  is 
quite  straightforward,  as  illustrated  in  figure  5-3.  GPS  scene 
imagery  From  the  day  and  thermal  channels  appear  in  the  gunner’s 
monocular  eyepiece  and  is  optically  relayed  to  the  commander’s 
station  via  a  GPS  extension  (GPSE)  .  Thermal  imagery  from  the  CITY 
is  combined  with  overlay  symbology  and  presented  to  the  commander 
on  a  biocular  crt  display  .  The  gunner  does  not  have  access  to 
this  display .  Control  of  the  thermal  imagers  is  provided  through 
hard  switches  located  on  the  GPS  and  on  the  CITY  control /display 
box . 


Figure  5-3.  fllAl  FCS  Operator  Interface  and  Communications 


The  other  major  control  interface  to  the  FCS  is  through  the 
computer  control  and  display  unit.  This  panel  has  a  5  character 
LED  display,  numeric  keypad,  toggle  switches,  and  data  select 
buttons.  It  is  used  to  control  the  computer  moding,  as  a  control 
interface  during  system  alignment  and  zeroing,  and  to  manually 
insert  data  estimates  for  selected  fire  control  parameters. 

As  currently  configured,  there  is  little  flexibility  in  the 
control/display  functions  and  formats  that  can  be  generated. 
However,  Control  Data  Corporation  has  recently  announced  an 
improved  version  of  the  CDU  that  will  provide  considerably  mare 
flexibility,  including  (possibly)  the  ability  to  display  limited 
BUS  data  at  the  gunner’s  station  if  the  proper  interfaces  are 
included . 


5.3  fllAl  BMS  REQUIREMENTS 

The  M1A1  Block  II  Improvement  Program  (scheduled  for  production 
in  1988),  has  defined  some  preliminary  requirements  for  a  base¬ 
line  vehicle-integrated  BMS  capability.  These  include: 

-  A  Control  and  Display  Panel,  including  a  Uideo  Display  for 

sight  imagery  and  Overlaid  symbols,  a  Uideo  Message  Dis¬ 
play,  and  a  CITU  Control  System. 

-  A  MIL-STD-1553  Data  Bus  with  growth  potential  for  remote 

terminals  at  all  electro-mechanical  tank  subsystems. 

-  BMS  interface  via  1553  data  bus  to  SINC3AR5  radio  system. 

-  A  Digital  Map  (cassette  or  video  disk  storage),  and  display 

-  A  Heading  Reference  System 

-  Identification  Friend  or  Foe  System 

-  A  coordinating  Processor  with  growth  capability 

The  Following  paragraphs  brieFly  summarize  the  elements  of  the 
B^S  as  viewed  in  late  1985. 

5  3.1  Control  and  Display  Panel 

”k'e  9hS  display,  operator  input  and  control  Functions  will  be 
”'":v:ded  within  this  function.  Extensive  studies  on  the  Soldier- 
Interface  including  the  display  and  control  features  have 
•  *''  '-ece^tly  performed  at  Ft.  Knox.  Features  include: 

..■tec  message  display  -  for  system  prompts  and  commun- 
■  at .3"s  with  external  elements 

■*.a:  .  For  Graphic,  symbolic  and  alpha-numeric  display 
*  teratcr  entry  of  drawings,  symbols  and  text. 


Selective  control  of  system  and  display  features  to  provide 
operator  flexibility  of  use 

5.3.2  Mil  Std  1553  Data  Bus 

To  provide  an  expansion  path  with  flexibility  for  connection  of 
system  elements,  a  niL-STD  1553  data  bus  has  been  specified  for 
use  in  communication  between  B(1S  system  elements,  and  for  inter¬ 
facing  to  other  on-board  systems.  Section  H.2.2  of  this  report 
includes  a  discussion  of  Mil  Std  1553  and  other  interconnection 
and  networking  systems.  The  stated  intent  is  to  "allow  growth 
potential  to  interconnect  via  remote  terminals  to  all  electro¬ 
mechanical  tank  subsystems.” 

5.3.3  BMS  interface  via  1553  data  bus  to  SINCGARS  radio  system 

SINCGARS  radio  systems  are  designated  to  receive  and  transmit 
data  generated  by  or  supplied  to  the  vehicular  BMS.  The  B(1S 
system  will  include  a  1553  data  bus  interface  with  SINCGARS  and 
data  formatting/buffer  storage  to  facilitate  data  management. 
Data  formats  and  multi-node  net  management  studies  shall  be 
developed  along  with  a  digital  data  management  study . 

5. 3. 4  Digital  (lap  (cassette  or  video  di3k  storage),  and  display 

On-board  storage  and  display  (via  the  BMS  display)  of  digital 
maps  are  required.  These  digital  maps,  associated  symbology  over¬ 
lays  and  text  will  form  the  bulk  of  BI1S  related  displays  and 
reports.  Navigational  and  operational  information  shall  appear  on 
the  display  correctly  scaled  and  positioned  in  respect  to  the  map 
data.  These  maps  shall  provide  different  scale  factors  and  the 
display  system  shall  provide  the  flexibilty  of  selective  display 
of  desired  features. 

5.3.5  Heading  Reference  System 

A  navigational  system  capable  of  accepting  digital  data  trans¬ 
missions  of  position  location  or  heading  reference  data  from  an 
accompanying  unit  or  vehicle  shall  be  provided.  This  system  shall 
provide  for  the  varying  levels  of  on-board  navigational  equipment 
depending  upon  level  of  command  and  control  .  The  resulting 
navigational  information  shall  be  displayable  as  required,  and 
available  to  other  BUS  system  elements. 

5.3.6  Identification  FriBnd  or  Foe  System 

A  system  providing  identification  of  other  combat  vehicles  on  the 
battlefield  as  either  friend  or  foe  shall  be  supplied.  It  is 
desirable  that  the  system  be  completely  passive  (no  energy 
emission) .  Less  desireable  would  be  an  active  or  an  active/ 
transpondmg  cooperative  system. 


5.3.7  Coordinating  Processor 


A  processing  system  which  controls  and  coordinates  the  actions  of 
all  BUS  system  elements  shall  be  provided.  It  shall  include 
storage  capacity  for  data  generated  by  the  above  systems  plus 
logistics,  maintenance  and  additional  operational  information. 
Sufficient  growth  capability  to  handle  expanded  Data  Bus  vehicle 
management,  enhanced  BUS  software,  and  future  artificial  intel¬ 
ligence  applications  shall  be  provided. 


5-15 


6.  ARCHITECTURES  FOR  M1A1  FCS/BMS 


This  section  describes  alternative  architectures  Far  incorpor¬ 
ating  a  BtlS  node  into  the  M1A1 .  They  are  evaluated  For  near  term 
impact  and  growth  in  both  the  BUS  and  FCS  systems. 

The  architectures  are  presented  in  block  diagram  Format  and,  For 
clarity,  the  pointing,  moding  and  control  aspects  are  discussed 
separately  From  the  communications  and  inFormation  display  and 
control . 

Section  B.l  describes  an  "add-on  BUS  node”  approach,  which 
minimizes  near  term  cost  and  design  impact  on  the  M1A1 .  It  has 
capacity  For  growth  within  the  BMS  Function,  but  does  not  address 
FCS  issues,  including  growth  or  design  changes  that  may  be 
required  as  a  result  oF  armor  and  armament  enhancements. 

Section  G.2  describes  an  architecture  that  has  greater  near  term 
impact  on  the  M1A1  design.  This  system  represents  an  integrated 
approach  to  FCS  and  BMS  processing  and  addresses  some  near  term 
Fire  control  problems  as  well  as  the  new  BMS  requirements.  It  is 
more  growth  oriented  than  the  add-on  BUS  approach  and  provides  a 
mechanism  for  FCS  and  BMS  changes  that  will  occur  in  the  3  to  5 
year  timeframe  while  retaining  much  of  the  current  FCS  structure. 

Section  6.3  describes  a  bus-oriented  approach,  which  will  be 
required  when  the  longer  term  performance  and  functional  growth 
objectives  became  reality.  It  is  structured  around  technology 
that  is  available  today,  but  may  not  be  cost  effective  to 
implement  immediately.  As  shown,  the  system  has  the  capability 
for  large  scale  image  processing  in  both  the  FCS  and  BMS .  The 
tr  nsition  from  the  previously  described  concepts  to  this 
structure  is  also  discussed. 

Section  6.4  summarizes  the  relative  merits  and  shortcomings  of 
each  of  the  above  approaches  and  establishes  some  recommendations 
Far  proceeding  with  this  aspect  of  the  M1A1  Block  II  program. 

6.1  "ADD-ON "  BMS  NODE 

This  represents  the  lowest  cost/risk  approach  For  a  near-term 
stand-alone  BMS  node,  and  is  similar  to  the  approach  originally 
shown  in  the  M1A1  Block  II  design  and  integration  planning 
documents  Cref.  Figure  6-1).  This  architecture  addresses  only  the 
stand-alone  BMS  requirements,  with  the  primary  Focus  on  the  near 
term.  As  such,  it  minimizes  the  immediate  impact  on  the  M1A1 
technical  configuration  and  schedule. 

The  major  shortcoming  of  this  approach  is  that  it  is  developed 
independent  of  Fire  control  considerations  and  is  not  inherently 
compatible  with  expanding  the  BMS-FCS  interfaces.  From  an  inte¬ 
gration  point  of  view,  this  approach  is  straightforward,  and 
assuming  the  required  turret  "real  estate”  is  available,  presents 
no  significant  technical  problems  or  design  impacts  to  the 
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Figure  6~1 .  Initial  BUS  Module  Concept 
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current  interconnect. 


However,  it  is  reasonable  to  assume  that  fire  control  improve¬ 
ments  will  occur  in  the  near  Future  -  most  probably  with  respect 
to  gun/turret  stabilization  C including  barrel  dynamics)  and 
firing  logic.  Additionally,  recent  UHSIC  insertion  studies  have 
shown  that  the  ability  to  engage  non-cooperative  targets  can  be 
improved  substantially  with  more  sophisticated  reticle  control 
and  lead  computation.  If  the  BMS  and  FCS  architectures  are 
developed  independently,  there  is  a  high  liklihood  that  the 
resulting  turret  electronics  will  be  nonstandard,  costly, 
unnecessarily  complex,  and  very  difficult  to  integrate. 

6.1.1  POINTING,  MOOING  AND  CONTROL 

Figures  6-2  and  6-3  illustrate  the  architectures  For  the  Azimuth 
and  Elevation  channel  pointing,  moding,  and  control  functions 
respectively . 

The  BMS  interfaces  to  the  FCS  in  only  two  places:  a  digital  data 
link  to  the  ballistic  computer,  which  also  interfaces  to  a 
heading  reference  unit,  and  a  MIL-STD-1553B  interface  to  the  CITU 
electronics.  Only  the  MIL-STD-1553B  and  heading  reference  unit 
interfaces  affect  the  turret-based  control  functions. 

It  is  assumed  that  the  vehicle  commander  will  have  the  capability 
to  slew  his  CITY  to  a  potential  target  location  as  shown  on  his 
BMS  control/display  screen.  This  architecture  uses  the  1553B 
interface  capability  of  the  CITY  to  provide  that  control 
function.  Upon  command  from  the  BMS  display,  the  BMS  processor 
can  calculate  rates  and  durations  required  to  slew  the  CITU  to 
the  desired  heading.  The  required  moding  and  tracking  commands 
are  then  transmitted  to  the  CITU,  where  its  control  system 
responds  appropriately.  With  the  addition  of  tracking  commands  to 
the  block  data  list  for  the  CITU  1553B  interface  specification, 
it  appears  that  all  of  the  required  functions  can  be  accomplished 
through  this  interface. 

In  all  other  respects,  the  FCS  operates  exactly  the  same  as  the 
current  M1A1  FCS  in  both  axes. 

6.1.2  COMMUNICATIONS,  INFORMATION  DISPLAY  AND  CONTROL 

The  communications  and  information  display  architecture  for  this 
approach  is  shown  in  figure  6-4,  together  with  the  interfaces  to 
control  these  functions.  The  operator  interface  to  the  BMS  node 
occurs  primarily  through  a  touch-sensitive  multi-function  control 
and  display  panel,  as  described  by  the  recent  Fort  Knox  require¬ 
ments  study  Cref.  1). 

The  BMS  display  is  assumed  to  be  a  CRT,  and  is  interfaced  to  the 
SMS  processor  through  a  direct  video  link  and  a  serial  digital 
line.  Consideration  was  given  to  including  a  screen  memory  and 
all  of  the  video  refresh  electronics  in  the  display  unit.  Since 
the  BMS  displays  change  relatively  slowly,  this  would  allow  the 
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interface  to  the  proceeaor  to  become  a  simple  digital  link  in 
which  only  changas  to  tha  display  would  ba  transmitted  as 
requirad . 


Howavar ,  this  could  also  limit  tha  flexibility  of  the  system. 
Specifically,  tha  BhS  display  could  serve  as  a  backup  for  sight 
imagery  as  tha  system  grows.  This  would  require  a  video  frame 
rata  update  of  the  entire  screen.  The  routing  of  video  data  will 
be  controlled  by  one  of  the  primary  computers  that  knows  the 
complete  systam  status  and  moding,  and  it  appears  that  a  straight 
video  interface  would  be  more  straightforward  and  compatible  with 
both  operating  modes. 

Communications  to  BflS  nodes  on  other  vehicles  is  conducted 
through  a  SINCGARS  radio  which  is  interfaced  to  the  BtlS  via  the  ! 

niL-STD-1553B  bus.  Designation  and  monitoring  of  frequencies  is 
accomplished  through  the  display  panel,  and  incoming  message 
alerts  are  displayed  on  the  panel . 

Heading  reference  data  for  display  and  use  in  the  CITU  control 
function  is  derived  from  an  RS-H22  data  link.  A  similar  link  is 
made  to  the  ballistic  computer  to  gain  access  to  internal 
computer  variables.  Initially,  it  is  anticipated  that  range  data 
will  be  used  far  computing  target  location,  and  crosswind  data 
may  be  used  m  conjunction  with  NBC  detectors  to  report  current 
and  probable  future  contamination  areas. 

Digital  terrain  map  data  is  available  from  a  mass  data  storage 
device  Ce.g.,  ruggedized  or  laser  disk).  The  BHS  processor 
accesses  portions  of  this  data  that  are  relevant  to  the  current 
situation  and  moves  them  to  a  working  memory,  where  they  can  be 
operated  on  for  video  overlay,  scaling,  and  display  processing. 

The  GPS  TIS  video  data  has  also  been  routed  to  the  CITU  elec¬ 
tronics  for  display  to  the  commandsr  upon  selection.  This 
capability  alleviates  the  need  to  retain  the  current  optical 
relay  from  the  GPS  to  the  commander’s  station,  which  in  turn, 
frees  up  additional  space  for  integrating  the  BflS  control/display 
panel  . 

6.1.3  ELECTRON  I CS  CHANGES 

Table  6-1  summarizes  the  major  electronics  changes  that  would 
result  from  this  architecture,  using  the  N1A1  +  CITU  as  a  base¬ 
line.  Because  this  is  basically  a  standalone  BUS  add-on,  the  bulk 
of  the  electronics  changes  are  related  to  the  additional 
functions  being  implemented  via  BUS. 

The  only  hardware  changes  of  consequer.ce  to  the  current  FCS 
electronics  would  be  the  addition  of  a  digital  data  link  to  the 
ballistic  computer,  routing  of  the  TIS  video  to  the  CITU  display, 
and  the  implementation  of  the  CITU  1553B  interface,  which  was 
initially  specified  as  a  growth  item  for  that  device.  Some  minor 
reprogramming  of  the  ballistic  computer  would  also  be  required. 


Tabla  6-1.  Design  Impact:  Add-On  BP'S  Node 


ELECTRONICS  UN.T 

REQ'O  FOR 
BASE  BMS 

GROWTH 

ORIENTED 

CHANGES/REMARKS 

Computer  Electronics  Unit 

X 

Add  a  digital  data  link  (RS-422)  to  the  BMS  Processor 

Cl TV  Electronics 

X 

X 

Activate  the  MIL-STD-1553B  Interface  and  add 
tracking  commands  to  the  data  block  definition. 

Modify  to  accept  and  display  GPS  TIS  video. 

GPS  TIS  Electronics 

X 

Modify  to  send  video  signal  to  CITV  electronics. 

GTD  Electronics 

No  Change. 

BMS  Processor  Assembly 

X 

Nee  electronics  box  -  approximately  7"x7"x8" 

Contains  CPU/Memory,  dual  1553B  controller,  video  and 
digital  I/O. 

MIL-STD- 19530  Bus 

X 

Nee  interface  -  connects  BMS  processor,  CITV,  and 
SINCGARS  radio. 

Terrain  Map  Storage  Device 

X 

Nee  electronics  box  -  60  MByte  video  cassette  or  disk; 
Approximately  6"xl2"x20"  (assuming  disk). 

BMS  Display  &  Control  Panel 

X 

Nee  Electronics  box  -  Approximately  7.5"x7.5"x12" 
(Assumes  minimum  CRT  configuration) 

Heading  Reference  Unit 

X 

Nee  Electronics  box 

The  BMS  processor  is  a  new  electronics  assembly  which  reflects 
design  standards  that  will  maximize  its  compatibility  with 
functional  growth  and  UHSIC  insertion.  It  will  also  be  able  to 
taka  advantage  of  other  processor  module  developments  within  the 
tri-services  as  they  become  available. 

Three  primary  standards  have  been  assumed  for  this  assembly: 

Cl)  1750A  DoD  standard  Instruction  Set  Architecture 

C2)  IBUS  compatible  interconnect  between  the  card  modules 

C3)  SEM-E  electronic  module  packaging  format 

For  simplicity,  the  power  conditioning  module  has  not  been  shown 
in  the  system  block  diagrams.  In  addition  to  that,  the  processor 
assembly  consists  of  the  following  electronic  modules: 

17S0A  CPU  +  Memory  Module 

This  is  a  single  card  module  containing  the  1750A  CPU, 
256  K-words  of  RAM,  and  an  IBUS  control  interface.  It 
is  assumed  to  be  based  on  ULSI  technology  and  have  a 
nominal  throughput  of  1  MIP. 

Global  Memory  Module 

This  is  a  single  card  containing  non-volatile  elec¬ 
trically  alterable  memory. 

Dual  1553B  Bus  Controller 

This  is  a  single  card  capable  of  controlling  two  dual- 
redundant  1553B  data  buses.  Only  one  of  the  interfaces 
is  active  in  this  configuration. 

Uideo  Board 

Converts  BMS  display  data  to  standard  composite  video 
format  for  routing  to  the  BMS  display. 

Digital  I/O  Board 

Contains  serial  digital  interfaces  CRS422)  for  inter¬ 
facing  to  the  ballistic  computer  heading  reference,  and 
BMS  display  units. 

The  cards  are  mounted  in  an  expansion  chassis  (which  may  contain 
empty  slots  for  growth)  and  are  connected  through  backplane 
wiring.  The  IBU5  compatibility  will  allow  the  addition  or 
replacement  of  existing  cards  with  UHSIC  modules  when  the  need 
arises.  The  SEM-E  format  was  selected  because  it  appears  to  be 
the  focal  point  of  several  development  programs  and  is  compatible 
with  efficient  packaging  of  all  of  the  electronics  technologies 
of  concern  to  this  study . 
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The  "Add-On”  BMS  Node  approach  does  not  result  in  the  elimination 
of  any  of  the  existing  turret  electronics  boxes.  The  changes 
required  on  existing  boxes  should  not  affect  their  space  claim. 
The  net  change  in  turret  stowage,  then  is  the  addition  of  a  BMS 
processor  (approx.  7"x7”x8”),  a  BMS  display  unit  (approx. 
7 .5”x7 .5”xl2”) ,  a  heading  reference  unit,  and  a  digital  map 
storage  device  (approx.  6”xl2”x20”3  -  plus  the  associated  inter¬ 
connect  . 

6.2  BASELINE  INTEGRATED  FCS/BMS 

This  architecture  is  designed  to  provide  growth  capability  while 
minimizing  impact  on  the  current  electronics  boxes.  It  estab¬ 
lishes  a  baseline  from  which  the  high  probability  FCS  and  Bns 
growth  paths  can  be  most  easily  implemented  as  the  required 
technology  matures.  It  is  based  on  a  multi-processor  expandable 
computer  assembly  housing  Standard  Electronic  Modules  and 
standardized  module  interface. 

This  approach  reduces  the  volume  occupied  by  the  BMS  and  FCS 
electronics  elements  by  integrating  both  computing  Functions  into 
a  single  assembly  and  employing  sensor  sharing  where  possible. 
The  near  term  impact  of  this  on  the  M1A1  system  design  is  more 
substantial  than  the  Add-On  BMS  approach  described  above, 
although  the  overall  technical  risk  is  low. 

To  maximize  flexibility,  the  proposed  processor  approach  uses  the 
same  MIL-STD-1750A  computer  architecture  and  packaging  concept 
described  above.  The  chassis  is  plug-compatible  between  UL5I  and 
UHSIC  technology,  and  can  accept  additional  modules  as  system 
needs  grow.  The  processor  assembly  concept  is  compatible  with  the 
requirements  established  in  the  ARDC-sponsored  Common  Module  Fire 
Control  Study . 

The  processor  uses  essentially  the  same  modules  as  described  in 
the  preceeding  section,  except  that  it  requires  the  addition  of 
an  analog  I/O  module  and  uses  one  additional  CPU/Memory  module 
due  to  the  additional  computational  load  For  fire  control 
functions . 

This  architecture  brings  all  major  data  and  control  signals 
directly  to  the  processor  assembly.  Multiple  CPU’s  are  operating 
within  the  assembly,  and  each  can  access  a  global  (shared)  memory 
and  any  of  the  I/O  modules  as  required.  All  of  the  modules  are 
interconnected  by  dual  redundant  high  speed  internal  buses  CIBUS) 
in  the  chassis  backplane. 

There  are  several  significant  advantages  to  this  architectural 
approach : 


1 . 


This  configuration  will  be  low  risk  and  occupy  the 
least  volume  for  a  given  level  of  system  computation 
and  memory  requirements. 


2. 


Sensor  data  sharing  between  various  Fire  control  and 
BflS  Functions  is  Facilitated.  This  reduces  the  number 
oF  sensors  and  net  volume  occupied  by  them  in  the 
system . 

3.  Multi-processors  plus  the  availability  oF  all  data 
through  the  intermodule  bus  and  shared  memory  provides 
Full  computational  redundancy  For  all  Functions. 

4.  The  standards  imposed  on  this  design  make  it  plug 
compatible  with  ongoing  UHSIC  developments.  Thus,  com¬ 
putation  growth  can  be  accomplished  by  straight  module 
replacement,  with  no  external  system  impact.  The  non- 
proprietary  internal  bus  structure  will  allow  open 
competitive  procurement  at  the  module  level . 

5.  IF  required,  physical  expansion  oF  the  assembly  can  be 
accomplished  by  initially  providing  empty  module  slots 
or  by  transFerring  the  modules  to  a  chassis  with 
adoitional  slats  and  adding  the  required  modules. 

The  major  disadvantage  oF  this  architecture  From  an  integration 
point  oF  view  is  the  requirement  For  parallel  routing  oF  a 
relatively  large  number  oF  signals  tQ  the  processor  assembly  .  The 
requirement  For  the  baseline  systBm  doBS  not  appear  to  be 
excessive,  however.  The  current  J11A1  CEL)  interFace  includes  7  dc 
analog  signals  and  approximately  50  logic  level  lines.  This 
approach  will  result  in  an  additional  11  input  and  5  output 

analog  signals  at  the  processor  intBrFace.  Some  additional  logic 
level  lines  will  also  us  required. 

On  a  new  system  design,  the  generally  preFerred.  approach  would  be 
to  collect  the  various  signals  at  other  paints  in  the  system, 
Format  convert  them  as  necessary,  and  route  them  to  the  processor 
via  a  data  bus  or  dedicated  digital  interFace.  This  was  not 

selected  in  this  baseline  because  Cl)  the  design  impact  on  other 

subsystems  would  be  greater,  (2)  thBre  is  currently  no  bus  in 
place  on  the  vehicle  that  could  be  adapted  For  this,  and  C3)  the 
cost  oF  providing  suFFicient  bus  capacity  and  new  interfaces  for 
the  major  electronics  boxes  appears  to  be  quite  high. 

However,  as  requirements  grow,  bus  technology  advances.  a-d 

Uetronics  becomes  a  reality,  conversion  to  a  bus-based  ::-f 
structure  must  occur,  and  the  impact  on  the  processor 
minmal .  In  essence,  the  analog  I/O  module  will  be  rep.areo  . 
bus  interFace  module  meeting  the  external  and  inter- a* 
standards.  This  is  discussed  Further  m  sect:-,  o-  5  3 
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Baseline  Integrated  FCS/BMS  (Azimuth) 


There  are  some  fundamental  changes  in  the  implementation  of  the 
FCS  control  functions  relative  to  the  current  M1A1: 

Tracking  Command  Interface 

The  commander  and  gunner  control  handle  tracking  commands 
are  routed  to  the  computer,  which  formats  and  adjusts  them 
as  appropriate  before  routing  them  to  the  GPS  or  CITU.  This 
approach  allows  sensitivity  to  be  adjusted  as  a  function  of 
vehicle  dynamics  and  provides  an  Interface  for  a  variety  of 
tracking  aids,  Including  linear  motion  compensation  and 
automatic  target  tracking. 

This  also  provides  a  direct  access  for  command  response  of 
the  sights  to  stimuli  from  other  subsystems  such  as  the  BhS. 
This  interface ,  for  example,  would  allow  the  GPS  to  be 
slewed  directly  to  a  target  known  to  the  BhS,  without  the 
need  to  bring  the  CITU  to  bear  firet. 

Sensor  end  Control  Interfaces 

The  enelog  interfaces  to  current  eensors  and  control  elec¬ 
tronics  are  retained  along  with  the  current  (resolver  chain) 
sight-to-gun  position  references  and  OCX's  (Digital  Control 
Transformer's).  The  performance  of  these  elements  is 
adequate,  and  the  technical  and  cost  risks  of  converting 
them  to  data  bus  formats  with  sufficient  throughput 
capability  are  quite  high.  The  required  analog/digital/ 
analog  conversions  are  accomplished  in  the  interface  elec¬ 
tronics  of  the  FCS/ BhS  processor. 

Stabilization  and  Line  of  Fire  Control 

The  eight  stabilization  electronics  remain  unchanged.  How¬ 
ever,  improved  reticle  control  algorithms  will  be 
implemented  in  the  FCS/BhS  processor. 

The  gun  and  turret  stabilization  function  has  been  digitized 
and  integrated  into  the  FCS/BhS  processor.  This  is  m 
response  to  the  need  for  improved  control  algorithms  to 
offset  the  destabilizing  effects  of  improved  mam  armament 
and  higher  armor  protection  levels. 

Gun  Barrel  Bend 

The  current  manual  muzzle  reference  system  is  supplemented 
or  replaced  with  a  barrel  dynamics  sensor.  If  the  strain 
gauge  technology  currently  employed  in  the  Ballistic 
Research  Labs  PATS  program  proves  to  provide  consistent 
static  as  well  as  dynamic  data,  the  current  rtRS  could  bo 
eliminated . 

Static  barrel  bend  is  used  to  automatically  compensate 
system  alignment  for  changes  induced  by  thermal  strsss. 
Dynamic  barrel  bend  is  used  for  stabilization  and  to  compute 


optimum  firing  opportunities. 


Turret  Orientation  and  Dynamics 

A  single  (new)  sensor  package  is  employed  to  support 
attitude,  heading,  ballistics,  and  stabilization  com¬ 
putations.  In  addition  to  providing  data  required  by  BflS  and 
improved  FCS,  this  allows  the  elimination  of  the  current 
static  cant  sensor  and  turret  pitch  rate  gyro.  For  Fire 
control,  this  provides  a  dual  purpose:  (1)  it  provides 
dynsmic  cant  and  pitch  information  for  ballistic  compen¬ 
sation  and  attitude  reference,  and  (2)  it  provides  turret 
pitch  and  roll  rates  and  vertical  and  lateral  accelaration 
measurements  for  weapon  stabilization.  The  acceleration 
measurements  are  used  to  compensate  the  increased  unbalances 
due  to  enhanced  weapons  and  armor .  The  turret  rates  are  used 
for  bsse  motion  bucking  and  roll  rate  compensation. 

For  BMS  purposes  this  sensor  provides  the  required  heading 
and  attitude  information  for  referencing  to  situation  dis¬ 
plays  end  targeting  information.  In  some  vehicles,  this  data 
can  be  processing  in  conjunction  with  other  sensors  to 
provide  a  complete  poaitlon  location  (navigation)  capability. 

The  processing  required  to  convert  the  basic  sensor  data 
into  attitude,  heading,  etc.  is  resident  to  the  FCS/BMS 
primary  processor. 

8.2.2  COMMUNICATIONS,  INFORMATION  DISPLAY  AND  CONTROL 

The  communications  architecture  for  this  system  is  shown  in 
figure  6-7  and  is  identical  to  that  described  in  the  proceeding 
section,  with  the  processor  interface  to  SINCBARS  being  through  a 
MIL— STD-1553B  data  bus. 

Similarly,  the  operator’s  interface  to  the  BMS  functions  is  via 
the  same  multi-function  control  and  display  panel.  In  conjunction 
with  the  replacement  of  the  current  ballistic  computer,  however, 
the  gunner's  computer  control  panel  has  been  upgraded  to  a  multi- 
line  electro- luminescent  design,  as  recently  shown  by  Control 
Data  Corporation  (figure  6-8) .  This  substantially  increases  the 
flexibility  of  information  presentation  to  the  gunner  and.  as 
implemented,  allows  this  same  equipment  to  be  used  for  displaying 
alphanumeric  BMS  data  at  the  gunner's  station. 

6.2.3  ELECTRONICS  CHANGES 

Table  6-2  summarizes  the  electronics  and  interconnect  changes 
that  would  result  from  this  architectural  approach.  The  assumed 
baseline  is  M1A1  *  C I TU  as  described  in  section  5.5.  Relative  to 
the  previously  described  add-on  BMS  approach,  the  major 
additional  changes  here  relate  to  removal  of  the  current 
ballistic  computer,  digitizing  the  gun/turret  control  laws, 
replacing  some  sensors  with  higher  performance  multi-function 
elements,  and  integration  of  the  new  software. 


Tabla  8-2.  Dasign  Impact:  Basal ina  Intagratad  FCS/BMS 


RtQ'O  FOR  MONTH 

OJBCTMMICt  UNIT  MX  BMI  ORIENTED  CHANBES/REMARKS 

fnnp  liter  Electronics  Unit  X  Replaced  by  FCS/ I CCS  Processor. 

Coa«Nr  Ola# lay  Fan* I  X  Naa  design  -  baaed  on  COC  Improved  CCP  concept. 

RS-422  Interface  to  FCS/ICCS  processor. 

Um  for  both  FCS  and  BMS  data  display. 


CITY  I lactroalea  X 

X 

W%  Tit  f lectronlcs  X 

•TO  Cl act row lea 
Hal  I  Rata  Qyro 
Turret  Pitch  Rata  Gyro 
Caat  Saws or 

Nuts  la  Reference  Syateai 

PCS/ I CCS  Processor  Assembly  X  X 

MIL-STD-I993B  Bus  X 

Terrain  Map  Storage  Device  X 

■W  Display  &  Control  Panel  X 


Activate  the  MIL-STD-1 5330  Interface  and  add 
tracking  commands  to  the  data  block  definition. 
Modify  to  acoapt  and  display  OPS  TIS  video: 

Accept  tracking  coaaaends  from  coeputer. 

Modify  to  sand  video  signal  to  CITY  electronics) 
Accept  tracking  coaaaends  froo  coeputer. 


New  electronics  box  -  approxlnately  7"x7"x10". 

Contains  CPU /Manor  y,  dual  13338  controller,  video  and 
digital  I/O,  analog  l/C. 

Noe  Interface  -  connects  BMS  processor.  Cl  TV,  and 
SINC6ARS  radio. 

Nse  electronics  box  -  60  MByte  video  cassette  or  disk; 
Approxlnately  6"x12"x20"  (assuming  disk). 

Nee  Electronics  box  -  Approximately  7.5"x7.5"x12" 
(Assumes  minimum  CRT  configuration) 


X  Simplify  -  r amove  compensation  and  settchlng  electronics. 

X  Reroute  to  FCS/ I CCS  processor. 

X  Eliminated. 

X  Eliminated. 

X  Add  dynamic  nuzzle  reference  sensor  and  route 

signals  to  PCS/ I CCS  processor. 


Attitude  A  Heeding 
Reference  Unit 


X 


X 


Nee  Electronics  box  - 

Route  signals  to  FCS/ 1  CCS  processor 


Figure  6-0.  Improved  Computer  Control  Panel 


The  current  fire  control  computer  system  is  replaced.  The  current 
interfaces  to  the  computer  remain  much  the  same,  but  have  been 
expanded  to  include  required  gun/turret  drive  signals  and  heading 
reference.  The  turret  pitch  gyro  and  cant  sensor  have  been 
eliminated  because  the  required  data  can  be  derived  from  the 
Heading  and  Attitude  Reference  sensor. 


The  FCS/BflS  processor  is  an  expansion  chassis,  mounting  back¬ 
plane  connected  standard  electronic  modules.  Internal  inter¬ 
connect  is  through  redundant  intermodule  busses.  This  u/as 
described  in  more  detail  in  section  5.1. 

The  Attitude  and  Heading  Reference  electronics  box  contains  only 
the  sensors  and  signal  interface  electronics.  The  computation 
functions  normally  contained  in  a  standalone  system  have  been 
incorporated  into  the  FCS/BflS  processor  to  reduce  space  require¬ 
ments  and  provide  redundancy . 
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6.3  GROWTH  AND  BUS-ORIENTED  ARCHITECTURES 


The  architectures  discussed  in  the  proceeding  sections  have  been 
oriented  primarilg  to  the  near  term  requirements  for  the  BfIS  and 
FCS,  with  different  levels  of  consideration  for  growth.  However, 
an  underlying  objective  was  to  limit  the  impact  on  system  elec¬ 
tronics  and  interfaces  external  to  the  digital  processing 
functions.  It  can  be  seen  that,  even  with  only  minor  growth  in 
capability,  the  ripple  effects  through  the  current  system  archi¬ 
tecture  can  be  substantial.  Thus,  the  attempt  was  to  examine 
compromises  that  did  not  preclude  orderly  -growth  while  minimizing 
near  term  cost  and  risk. 

In  the  long  term,  there  will  be  substantial  performance  growth  in 
both  the  FCS  and  the  BUS.  This  will  come  primarily  in  the  form  of 
more  sophisticated  processing  of  data  that  will  already  be 
available  on  the  vehicle  (although  not  necessarily  previously 
available  to  a  computer).  Thus,  the  physical  system  growth  will 
be  largely  reflected  in  expanded  data  flow  and  greater  com¬ 
putational  throughput. 

In  the  FCS,  much  of  the  growth  will  focus  on  video  data  proces¬ 
sing  to  further  automate  the  detection,  acquisition,  and  engage¬ 
ment  of  individual  targets.  It  will  include  automated  search, 
detection,  and  cueing  of  targets;  automatic  handoff  and  tracking 
through  the  gunsight;  and  image  processing  far  IFF  and  damage 
assessment.  In  the  BUS,  there  will  be  substantial  increases  in 
the  volume  of  communications,  the  automation  of  status  and 
logistics  reporting,  the  development  of  3-dimensional  battlefield 
and  line-of-sight  representations,  and  the  application  of 
artificial  intelligence  for  decision  aiding  and  situation 
assessment . 

The  growth  in  computational  throughput  associated  with  these 
functions  can  only  be  realized  through  the  use  of  UHSIC 
technology.  Both  the  FCS  and  BMS  will  require  this  technology  to 
achieve  the  performance  levels  described  above,  and  there  will  be 
substantial  sharing  of  data  between  the  two  functions. 

This  section  illustrates  a  system  architecture  that  is  compatible 
with  these  high  performance  levels.  It  is  an  upward  extension  of 
the  system  described  in  section  5.2,  and  it  employs  a  represen¬ 
tative  Uetronics-type  data  bus  interconnect  in  order  to  show  how 
a  near  term  solution  could  evolve  into  such  an  architecture. 

The  system  described  here  operates  using  two  primary  processors 
that  are  UHSIC  extensions  of  those  described  in  the  preceeding 
sections.  The  module  interconnect  and  physical  form  Factors  are 
identical  to  those  described  earlier.  The  physical  configurations 
of  the  two  processors  are  identical,  and  although  one  is 
nominally  Focused  on  BUS  processing  and  the  other  on  FCS  proces¬ 
sing,  each  is  capable  of  performing  the  other’s  functions  if 
required . 


System  control  and  data  distribution  occurs  through  three  types 
of  buses.  The  MIL-STD-1553B  bus  is  used  to  communicate  with  the 
radio  nets  as  in  the  previously  described  systems.  Depending  upon 
the  volume  of  communication,  two  separate  dual-bus  configurations 
may  be  required.  Houiever,  the  required  controllers  for  a  second 
bus  already  exist  in  the  1553B  processor  modules,  so  this  mould 
not  require  additional  processor  hardware. 

Tho  video  and  data  buses  are  patterned  after  the  corresponding 
elements  in  a  Uetronics  concept  currently  being  developed  by 
Texas  Instruments.  The  data  bus  interface  CDBIF)  and  video  bus 
interface  CUBIF)  are  also  assumed  to  be  functionally  equivalent 
to  those  described  by  Texas  Instruments  in  reference  10  and 
illustrated  in  figures  6-9  and  6-10,  which  are  reproduced  From 
that  report.  Although  specific  design  characteristics  of  the  FUC 
Uetronics  system  differ  from  this,  they  are  functionally  equiv¬ 
alent.  Therefore,  this  concept  would  be  usable  with  either 
Uetronics  approach. 

The  DBIF  consists  of  the  hardware  required  to  interface  with  an 
IEEE  602.5  standard  data  bus,  a  host  processor,  and  signal  inter¬ 
faces  for  other  equipment  typically  used  in  combat  vehicles.  It 
has  the  capability  to  reroute  signals  on  the  dual  ring,  bi¬ 
directional  bus  for  survivability  enhancement.  The  UBIF  can 
either  receive  or  transmit  data  to  a  video  data  bus  operating  at 
140  MHz.  It  operates  as  a  repeater  on  the  bus  and  can  reroute 
data  in  the  same  manner  as  the  DBIF. 

As  illustrated  in  Figures  6-11  through  6-13,  these  data  bus 
interface  modules,  which  can  be  packaged  as  a  single  electronics 
card  in  the  SEh-E  format  discussed  earlier,  are  used  For  signal 
interface  and  distribution  at  the  major  FCS/BMS  subsystems. 

Functionally,  this  system  differs  from  the  previous  system  in 
that  a  significant  video  processing  capability  has  been  added. 
UHSIC  video  processors  (consisting  of  an  array  processor  plus  a 
1750A  scalar  processor)  have  been  added  to  provide  capabilities 
for  automatic  target  search,  cueing,  and  tracking  using  the  video 
data  From  either  sight  and  For  generating  battlefield  perspective 
views  For  BMS .  These  functions  can  be  handled  in  either  the 
primary  FCS  processor  or  the  primary  BUS  processor,  depending 
upon  equipment  status  and  system  moding. 

The  azimuth  and  elevation  channel  pointing,  moding,  and  control 
architectures  are  illustrated  in  figures  6-11  and  6-12,  respect¬ 
ively  . 

Functionally,  the  control  interfaces  for  both  channels  are 
identical  to  those  described  in  the  proceeding  section.  However, 
rather  than  being  routed  to  and  From  the  processor  assembly  in 
their  natural  format,  the  interface  signals  for  each  subsystem 
are  converted  in  the  DBIF  and  transmitted  via  the  data  bus. 
Electronics  and  control  interfaces  within  the  sighting  and  gun 
drive  systems  remain  as  described  in  section  6.2. 


Figure  6-9.  Data  Bus  Interface 


OMITAk 

MWn 

<*41 


analob 

sr*” 


outputs 

a» 


jUgdklASY 


Figure  6-10.  Uideo  Bus  Interface 
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Figure  6-11.  Growth/Bus  Oriented  System  CAzimuth) 


The  communications  and  control/display  interface  is  illustrated 
in  figure  6-13.  As  with  the  control  functions,  the  various 
signals  are  interfaced  to  the  data  and  video  buses  at  the  sub¬ 
systems.  Communications  with  the  radios  is  accomplished  with  the 
1553B  bus  as  before,  although  it  has  been  assumed  that  additional 
equipment  may  be  used  due  to  a  higher  level  of  data  transfer  over 
a  number  of  networks. 

The  electronics  box  configuration  for  a  system  configured  like 
this  mould  be  similar  to  that  for  the  system  in  section  6.5. 
However,  signals  mould  not  require  routing  and  direct  connection 
to  the  main  processor  assembly.  The  DBIF  and  UBIF  are  each  con¬ 
figurable  on  the  standard  format  electronics  cards,  and  therefore 
could  be  configured  as  free  standing  interface  electronics  boxes 
or  be  intergated  into  one  of  the  existing  boxes,  depending  upon 
the  specific  physical  constraints  in  each  subsystem  area. 

6.4  RECOMMENDED  TECHNICAL  APPROACH 

Analysis  of  the  current  and  probable  growth  requirments  for  BMS 
and  FCS  lad  to  the  following  conclusions: 


Cl)  The  FCS  and  BMS  are  closely  interrelated.  When  project¬ 
ing  vehicle  design  impacts  they  must  be  considered 
together . 


(2) 


Both  the  FCS  and  BMS  functions  will  require  substan¬ 
tially  increased  processing  capability  over  the  next 
several  years . 


C3) 


The  similarity  of  control,  display,  and  data  require¬ 
ments  will  allow  some  vehicle  equipment  to  serve  both 
BMS  and  FCS  requirements. 


The  Ml  tank  is  already  close  to  its  capacity  far  stowage  of 
additional  turret  equipment  and  cabling.  Therefore,  components 
which  occupy  excessive  space  for  the  Function  provided  or  became 
redundant  when  BMS  is  implemented  should  become  candidates  for 
replacement  or  elimination.  The  current  ballistic  computer,  some 
of  the  fire  control  and  stabilization  sensors,  and  the  gun 
stabilization  compensation  electronics  appear  to  Fall  in  this 
category . 


The  implementation  of  any  level  of  BMS  capability  will  require 
additional  processing  capability  which  is  not  available  from  any 
of  the  current  turret  equipment.  When  viewed  ovBr  the  long  term, 
it  would  be  highly  desirable  that  any  new  processorCs)  take 
maximum  advantage  oF  current  technology  and  standardization. 


Growth,  multi-processor  architectures,  and  a  desire  to  standard¬ 
ize  equipment  across  the  widest  practical  range  of  vehicles  are 
key  issues  in  processor  architecture  selection.  It  is  recommended 
that  this  program  specify  the  following  for  any  new  Ml  processors: 
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(1)  Standard  Instruction  Set  Architecture 

Cl 750 A  Recommended) 

(2)  Standard  Electronic  Module  Format 

CSEM-E  Recommended) 

C3)  Standard  Inter-Module  Interconnect 

CIBUS  or  equivalent) 

(4)  Ada  High  Order  Language  Support 

Standardization  on  instruction  sets,  card  formats,  and  the 
elimination  of  proprietary  internal  buses  uiill  maximize  both  the 
grouith  compatibility  of  the  design  and  provide  the  broadest  base 
for  long  term  competitive  procurements.  Properly  specified,  this 
approach  will  be  compatible  with  UHSIC  developments  being 
sponsored  by  other  programs,  and  will  allow  direct  integration  of 
those  modules  as  they  become  available. 

All  of  the  concepts  discussed  earlier  in  this  section  presumed 
the  use  of  such  standards . 

The  "Add-On  BMS  Nods’*  approach,  when  viewed  strictly  from  a  near 
term  BMS  perspective,  may  appear  attractive.  It  has  the  least 
direct  impact  on  existing  equipment,  has  the  lowest  technical  and 
schedule  risk,  and  would  require  the  smallest  near  term  invest¬ 
ment.  By  employing  the  processor  standards  described  above,  it 
has  the  potential  far  growth  in  the  display  and  communications 
area,  but  does  not  not  address  the  corresponding  changes  required 
in  the  FCS.  This  approach  would  lead  to  uncoordinated  develop¬ 
ments  in  FCS  and  BMS  and  would  ultimately  result  in  higher 
development  cast  and  greater  integration  problems  for  the  total 
vehicle . 

The  bus-oriented  approach  described  in  section  6.3  represents  the 
cleanest  architectural  approach.  However,  it  also  has  the  most 
significant  impact  on  the  current  hardware,  and  would  require  the 
greatest  software  development  effort.  Additionally,  it  is  based 
an  the  implementation  of  Uetronics,  for  which  the  related 
military  standards  may  not  be  available  for  several  years. 
Commercial  standards  Ce.g.,  IEEE  802.5)  could  be  used  initially, 
but  there  would  still  be  substantial  risk  to  the  current  schedule 
objectives.  It  is  recommended  that  this  concept  be  phased  in  as 
the  requirements  grow  and  the  technology  and  Uetronics  standards 
become  available. 

The  recommended  initial  approach  is  to  follow  the  structure 
described  in  section  6.2  (baseline  growth-oriented  architecture), 
which  is  compatible  with  later  growth  to  Uetronics.  This  approach 
requires  some  substantial  changes  to  the  current  FCS  inter¬ 
connect,  conversion  of  the  current  fire  control  software  to  a  new 
structure,  and  the  development  of  digital  control  laws  for  the 
gun/turret  drives.  The  technical  risk  associated  with  these 
changes  is  low,  but  the  approach  is  probably  not  compatible  with 
the  current  production  break-in  objectives  for  BMS  on  M1A1 . 
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Howavsr ,  it  is  also  claar  that  tha  changas  dascnbad  abova  will 
hava  to  occur  somatima  in  tha  not  too  diatant  futura.  Tharafora 
tha  tachnical  and  long  tarm  coat  advantagaa  of  consolidating  BUS 
and  FCS  changaa  into  a  aingla  grouith-oriantad  daaign  changa  must 
ba  waighad  against  tha  disadvantagas  of  accapting  soma  slip  in 
tha  production  braak  in.  Thoaa  tradaofFs  ara  bagond  tha  scopa  of 
this  study . 
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1993  Military  Standard  Sarlal  Oata  But 

179QA  Military  Standard  16  Bit  Co— uter  Instruction  Sat 

Architecture 

1773  FI  bar  Optic  Equivalent  of  MIL-STD-1553 

ADC  Analog  to  Digital  Converter 

All  Araaaant  Enhanc— nt  Initiative 

AFATDS  Advanced  Field  Artillery  Target  Designation  Systen 

AMC  Amy  Materiel  Co— nd 

APC  Areored  Personnel  Carrier 

APU  Auxf Illary  Power  Unit 

AMDC  Anaanent  Research  t  Bevel— —nt  Center 

ATM  Air  Transport  Rack 

BIPF-M  Battlefield  Identification  Friend  Foe  -  Neutral 
(Used  Interchangeably  with  IFF,  BIFF) 

BIM  Bus  Interface  Module 

BIT  Built  In  Test 

BMS  Battlefield  Management  Systee 

CEO I  Coanun I cat 1 on  Electronic  Operating  Instructions 

Cl  TV  Co— an  Par’s  Independent  Ther—  I  viewer 

CPU  Central  Processor  Unit 

CRT  Cathode  Ray  Tube 

OAC  Digital  to  Analog  Converter 

OCT  Digital  Control  Transforner 

000  Depart— nt  of  Oef— so 

OMC  Digital  to  Resolver  Converter 

EL  E  lectro-L— I  nascent 

EMI  Electro  Mag— tic  Interference 

OT  Electro  Mag— tic  Pulse 

ETL  Engineer  Topographic  Laboratories 

FACS  Future  Arno red  Co— at  Syst— 

FCCVS  Future  Close  Co— at  V—  Icle  Study 

FCS  Fire  Control  System 

FOV  Field  of  view 

Goes  General  Dynamics  -  Land  System  Division 

GPS  Gunner's  Primary  Sight 

GTD  Gun/Turret  Drive  (and  Stab  1 1 1 zatlon)  System 

I BUS  Internal  Bus  Standard  (for  Module  Interconnect) 

I  CCS  Integrated  Co— and  and  Control  System  -  used 

Interchange— I y  with  *veh I c I e-besed  BMS  node* 
IRNS  Internal  Reference  Navigation  System 

ISA  Instruction  Set  Architecture 

JTIOS  Joint  Tactical  Information  Distribution  Syst— 

LAV  Light  Armored  Vehicle 

LCC  LI fe  Cycle  Cost 

LCD  Liquid  Crystal  Display 

LEO  Light  Emitting  Diode 

LHX  Light  Nolle— ter  Experimental 

LOS  Line  of  Sight 

LAM  Line  A—  lace—  le  Module 

LSI  Large  Scale  Integration 

Ml  U.S.  Army  Ml  Main  Battle  Tank 

M1AI  Enhanced  Version  of  Ml  Tank 

MAPS  Modular  Atlmuth  Position  Syst— 
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mc r 

MCS 

MIPS 

MOPS 

MOOT 

MP6S 

MSI 

MTBF 

NBC 

PPPI 

RAM 

ROC 

ROM 

RT 

SAPS 

SEM 

SHORAD 

SINCGARS 

SMI 

SOP 

TC 

TIS 

TNB 

UTM 

V(IMT)2 

VHSIC 

VISTA 

VLSI 

Ve+ron  I  c* 


Military  Cosputar  Fanil y 

Maneuver  Control  System 

Million  Instructions  Par  Sacond 

Million  Operations  Par  Second 

Mounted  Operation  In  Urban  Tarraln 

Mob I le  Protected  Sun  Systae 

Med I ue  Scale  Integration 

Mean  Tina  Between  Failures 

Nuclear  Biological  Chemical 

Preplanned  Product  Improvements 

Random  Access  (Read-Write)  Memory 

Resolver  to  Olgttal  Converter 

Read  Only  Memory 

Remote  Terminal 

Stored  Adress  Parameter  Set 

Standard  Electronic  Module 

Short  Range  Air  Defense 

Single  Channel  Ground  and  Air  Radio  System 

Soldier  Machine  interface 

Standard  Operating  Procedure 

Tank  Commander 

Thermal  Imaging  Sight 

Turret  Networks  Box 

Universal  Transverse  Mercator;  position  grid  coordinates 
Northing,  Easting,  hemisphere,  and  zone. 

Vehicle  Integrated  Intelligence 

Very  High  Speed  Integrated  Circuits 

Very  Intelligent  Surveillance  and  Target  Acquisition 

Very  Large  Scale  Integration 

Vehicle  Electronics  (Data  Bus  Architecture) 
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APPENDIX  C: 

I  CCS  FORCE  DISTRIBUTION  ANO  NETWORK  INTERFACE 
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BUS  HARDWARE  DISTRIBUTION  -  PLATOON 
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SENSOR  DEVICES 


BMS  INFORflATION  FLOW  -  PLATOON 
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